perm filename COMMON.10[COM,LSP] blob
sn#851152 filedate 1988-01-01 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00655 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00093 00002
C00094 00003 ∂12-Apr-87 0005 kempf%hplabsc@hplabs.HP.COM Re: redefining Common Lisp functions
C00097 00004 ∂12-Apr-87 1750 edsel!bhopal!jonl@navajo.stanford.edu all symbols [and delayed mail]
C00102 00005 ∂12-Apr-87 1751 edsel!bhopal!jonl@navajo.stanford.edu redefining Common Lisp functions
C00104 00006 ∂12-Apr-87 2225 HEWETT@SUMEX-AIM.STANFORD.EDU Redefining CL fns
C00106 00007 ∂13-Apr-87 1018 sears%wrs.DEC@decwrl.DEC.COM Re: Redefining Common LISP Functions, MACROS and Special Forms
C00110 00008 ∂13-Apr-87 1216 gls@Think.COM redefining Common Lisp functions
C00113 00009 ∂13-Apr-87 1516 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Compiling CASE
C00119 00010 ∂13-Apr-87 1528 @diamond.s4cc.symbolics.com:DCP@QUABBIN.SCRC.Symbolics.COM Compiling CASE
C00125 00011 ∂13-Apr-87 2016 DON%atc.bendix.com@RELAY.CS.NET Inconsistent keywords for sequence functions
C00127 00012 ∂14-Apr-87 0747 ROSENKING@A.ISI.EDU Redefinition of CL Functions
C00134 00013 ∂14-Apr-87 0851 kempf%hplabsc@hplabs.HP.COM Re: Redefinition of CL Functions
C00137 00014 ∂14-Apr-87 0924 RAM@C.CS.CMU.EDU Redefinition of CL Functions
C00140 00015 ∂14-Apr-87 0949 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Redefinition of CL Functions
C00143 00016 ∂14-Apr-87 1010 sears%wrs.DEC@decwrl.DEC.COM Re: Inconsistencies in Sequence Function Arguments
C00145 00017 ∂14-Apr-87 1013 Moon@STONY-BROOK.SCRC.Symbolics.COM Inconsistent keywords for sequence functions
C00148 00018 ∂14-Apr-87 1131 Moon@STONY-BROOK.SCRC.Symbolics.COM redefining Common Lisp functions
C00152 00019 ∂14-Apr-87 1148 VERACSD@A.ISI.EDU Format
C00153 00020 ∂14-Apr-87 1204 FAHLMAN@C.CS.CMU.EDU Format
C00155 00021 ∂14-Apr-87 1706 sears%wrs.DEC@decwrl.DEC.COM Re: Redefinition of CL Functions
C00158 00022 ∂14-Apr-87 1829 jcm@ORNL-MSR.ARPA Flavors and DEC's VMS Common Lisp?
C00160 00023 ∂14-Apr-87 2056 kempf%hplabsc@hplabs.HP.COM Re: Redefinition of Common Lisp Functions
C00165 00024 ∂14-Apr-87 2256 MURRAY%cs.umass.edu@RELAY.CS.NET EVAL-WHEN symbols
C00167 00025 ∂15-Apr-87 0236 pyramid!pyramid.UUCP!bein@hplabs.HP.COM macroexpand inside of macrolet...
C00171 00026 ∂15-Apr-87 0818 FAHLMAN@C.CS.CMU.EDU Redefinition of Common Lisp Functions
C00174 00027 ∂15-Apr-87 0818 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM macroexpand inside of macrolet...
C00177 00028 ∂15-Apr-87 0903 FAHLMAN@C.CS.CMU.EDU EVAL-WHEN symbols
C00179 00029 ∂15-Apr-87 0955 weeks%hplbgw%hplb29a@hplabs.HP.COM Re: EVAL-WHEN symbols
C00181 00030 ∂15-Apr-87 0957 Masinter.pa@Xerox.COM Re: macroexpand inside of macrolet...
C00183 00031 ∂15-Apr-87 1034 Masinter.pa@Xerox.COM Re: EVAL-WHEN symbols
C00185 00032 ∂15-Apr-87 1306 Mailer@XX.LCS.MIT.EDU Compiling CASE
C00188 00033 ∂15-Apr-87 2258 sandra%orion@cs.utah.edu bignums are bogus
C00193 00034 ∂16-Apr-87 0834 FAHLMAN@C.CS.CMU.EDU bignums are bogus
C00196 00035 ∂16-Apr-87 0834 RAM@C.CS.CMU.EDU bignums are bogus
C00201 00036 ∂16-Apr-87 0837 vrotney@vaxa.isi.edu CLARIFICATION: [italics]package arguments.
C00203 00037 ∂16-Apr-87 0859 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM bignums are bogus
C00206 00038 ∂16-Apr-87 0930 DLA@DIAMOND.S4CC.Symbolics.COM bignums are bogus
C00207 00039 ∂16-Apr-87 0946 RPG a lisp1 compatible subset of Common Lisp
C00221 00040 ∂16-Apr-87 1009 shebs%orion@cs.utah.edu Bognumosity
C00224 00041 ∂16-Apr-87 1042 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: bignums are bogus
C00227 00042 ∂16-Apr-87 1054 FAHLMAN@C.CS.CMU.EDU Bognumosity
C00230 00043 ∂16-Apr-87 1124 KMP@STONY-BROOK.SCRC.Symbolics.COM bignums are bogus, but so are fixnums
C00236 00044 ∂16-Apr-87 1211 shebs%orion@cs.utah.edu Re: Bognumosity
C00241 00045 ∂16-Apr-87 1216 DALY@IBM.COM typos in Cltl
C00242 00046 ∂16-Apr-87 1237 hoey@nrl-aic.ARPA Re: Bognumosity
C00244 00047 ∂16-Apr-87 1310 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Bognumosity
C00247 00048 ∂16-Apr-87 1317 sdcrdcf!darrelj@CS.UCLA.EDU Re: bignums are bogus
C00250 00049 ∂16-Apr-87 1349 @SAIL.STANFORD.EDU:REM@IMSSS How much memory for bignum or other large data structure?
C00261 00050 ∂16-Apr-87 1354 shebs%orion@cs.utah.edu Re: Bognumosity
C00264 00051 ∂16-Apr-87 1403 preece%mycroft@gswd-vms.ARPA Re: Bognumosity
C00268 00052 ∂16-Apr-87 1411 preece%mycroft@gswd-vms.ARPA Re: Bognumosity
C00272 00053 ∂16-Apr-87 1419 edsel!bhopal!jonl@navajo.stanford.edu bignums are bogus
C00275 00054 ∂16-Apr-87 1426 FAHLMAN@C.CS.CMU.EDU bignums are bogus, but so are fixnums
C00278 00055 ∂16-Apr-87 1511 Masinter.pa@Xerox.COM bignums are bogus
C00280 00056 ∂16-Apr-87 1513 hoey@nrl-aic.ARPA Re: How much memory for bignum or other large data structure?
C00285 00057 ∂16-Apr-87 1517 Pavel.pa@Xerox.COM Re: typos in Cltl
C00287 00058 ∂16-Apr-87 1605 sandra%orion@cs.utah.edu bugnums (er, bignums)
C00292 00059 ∂16-Apr-87 1632 ghenis.pasa@Xerox.COM SOME and Multiple Values
C00294 00060 ∂16-Apr-87 1652 Masinter.pa@Xerox.COM Uncle Lisp Needs You
C00296 00061 ∂16-Apr-87 1703 pyramid!pyramid.UUCP!bein@hplabs.HP.COM Re: Bognumosity
C00300 00062 ∂16-Apr-87 1703 ghenis.pasa@Xerox.COM SETF and pathname slots
C00302 00063 ∂16-Apr-87 1736 FAHLMAN@C.CS.CMU.EDU SOME and Multiple Values
C00304 00064 ∂16-Apr-87 1917 diamant%hpfclp@hplabs.HP.COM Re: CLARIFICATION: [italics]package arguments.
C00308 00065 ∂16-Apr-87 2012 DON%atc.bendix.com@RELAY.CS.NET Bignums are bogus?
C00310 00066 ∂16-Apr-87 2137 fateman@mike.Berkeley.EDU Re: Bignums are bogus?
C00312 00067 ∂17-Apr-87 0723 DLW@ALDERAAN.SCRC.Symbolics.COM Re: CLARIFICATION: [italics]package arguments.
C00315 00068 ∂17-Apr-87 0731 FAHLMAN@C.CS.CMU.EDU time to reactivate cl-cleanup
C00318 00069 ∂17-Apr-87 0959 RWK@YUKON.SCRC.Symbolics.COM SETF and pathname slots
C00321 00070 ∂17-Apr-87 1115 diamant%hpfclp@hplabs.HP.COM Re: CLARIFICATION: [italics]package arguments.
C00325 00071 ∂17-Apr-87 1122 Masinter.pa@Xerox.COM Re: time to reactivate cl-cleanup
C00327 00072 ∂17-Apr-87 1145 FAHLMAN@C.CS.CMU.EDU time to reactivate cl-cleanup
C00330 00073 ∂17-Apr-87 1200 Moon@ALDERAAN.SCRC.Symbolics.COM Language extensions (formerly [italics]package arguments.)
C00335 00074 ∂17-Apr-87 1329 FAHLMAN@C.CS.CMU.EDU Issue: FLET-IMPLICIT-BLOCK (Revision 4)
C00344 00075 ∂17-Apr-87 1408 FAHLMAN@C.CS.CMU.EDU Issue: FLET-IMPLICIT-BLOCK (Revision 5)
C00353 00076 ∂17-Apr-87 1525 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (version 2)
C00361 00077 ∂17-Apr-87 1536 Masinter.pa@Xerox.COM Issue FORMAT-ATSIGN-COLON (Version 3)
C00364 00078 ∂17-Apr-87 1608 vrotney@vaxa.isi.edu Re: CLARIFICATION: [italics]package arguments.
C00366 00079 ∂17-Apr-87 1633 Masinter.pa@Xerox.COM Issue IF-BODY (Version 3)
C00374 00080 ∂17-Apr-87 1634 Masinter.pa@Xerox.COM status.report
C00380 00081 ∂17-Apr-87 1737 FAHLMAN@C.CS.CMU.EDU Issue: COMPILER-WARNING-STREAM (Revision 4)
C00385 00082 ∂17-Apr-87 2007 FAHLMAN@C.CS.CMU.EDU Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
C00389 00083 ∂17-Apr-87 2109 vrotney@vaxa.isi.edu Sec.11.7 [italics]package arguments.
C00393 00084 ∂17-Apr-87 2121 edsel!bhopal!jonl@navajo.stanford.edu CLARIFICATION: [italics]package arguments.
C00397 00085 ∂17-Apr-87 2229 MURRAY%cs.umass.edu@RELAY.CS.NET OR and Multiple Values
C00400 00086 ∂17-Apr-87 2236 MURRAY%cs.umass.edu@RELAY.CS.NET Fixnums Bogus
C00402 00087 ∂18-Apr-87 0049 Mailer@XX.LCS.MIT.EDU OR and Multiple Values
C00409 00088 ∂18-Apr-87 0538 RPG Packages
C00410 00089 ∂18-Apr-87 1251 REM@IMSSS OR if some argument returns no values
C00412 00090 ∂18-Apr-87 1407 diamant%hpfclp@hplabs.HP.COM Re: CLARIFICATION: [italics]package arguments.
C00417 00091 ∂18-Apr-87 1444 FAHLMAN@C.CS.CMU.EDU OR if some argument returns no values
C00419 00092 ∂18-Apr-87 1628 Randy%acorn%LIVE-OAK.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: SETF and pathname slots
C00422 00093 ∂18-Apr-87 1922 FAHLMAN@C.CS.CMU.EDU Environment-Arguments
C00426 00094 ∂18-Apr-87 2215 MURRAY%cs.umass.edu@RELAY.CS.NET MULTIPLE-VALUE-OR, and Consing
C00430 00095 ∂19-Apr-87 1029 primerd!doug@enx.prime.pdn Bigosities
C00432 00096 ∂19-Apr-87 1726 sandra%orion@cs.utah.edu Re: Bigosities
C00435 00097 ∂19-Apr-87 1802 FAHLMAN@C.CS.CMU.EDU Issue ADJUST-ARRAY-DISPLACEMENT
C00442 00098 ∂19-Apr-87 2028 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue IF-BODY (Version 4)
C00458 00099 ∂19-Apr-87 2054 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: COMPILER-WARNING-STREAM (Revision 4)
C00466 00100 ∂19-Apr-87 2110 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
C00470 00101 ∂19-Apr-87 2115 FAHLMAN@C.CS.CMU.EDU Issue: COMPILER-WARNING-STREAM (Revision 4)
C00473 00102 ∂19-Apr-87 2134 FAHLMAN@C.CS.CMU.EDU Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
C00476 00103 ∂20-Apr-87 0625 DALY@IBM.COM Pavel's reply
C00477 00104 ∂20-Apr-87 0658 FAHLMAN@C.CS.CMU.EDU Issue IF-BODY (Version 4)
C00486 00105 ∂20-Apr-87 0658 preece%mycroft@gswd-vms.ARPA Bigosities
C00489 00106 ∂20-Apr-87 0805 gls@Think.COM bignums are bogus
C00491 00107 ∂20-Apr-87 1027 RPG On the Kanji feature of Common Lisp
C00495 00108 ∂20-Apr-87 1126 Pavel.pa@Xerox.COM Re: Issue IF-BODY (Version 4)
C00498 00109 ∂20-Apr-87 1235 Moon@STONY-BROOK.SCRC.Symbolics.COM MULTIPLE-VALUE-OR, and Consing
C00503 00110 ∂20-Apr-87 1236 Moon@STONY-BROOK.SCRC.Symbolics.COM Environment-Arguments
C00509 00111 ∂20-Apr-87 1448 Masinter.pa@Xerox.COM Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00512 00112 ∂20-Apr-87 1358 Masinter.pa@Xerox.COM Re: Issue IF-BODY (Version 4)
C00514 00113 ∂20-Apr-87 1358 Masinter.pa@Xerox.COM Re: Issue: COMPILER-WARNING-STREAM (Revision 4)
C00516 00114 ∂20-Apr-87 1420 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00522 00115 ∂20-Apr-87 1517 Masinter.pa@Xerox.COM status
C00529 00116 ∂20-Apr-87 1653 Masinter.pa@Xerox.COM Re: Issue ADJUST-ARRAY-DISPLACEMENT
C00531 00117 ∂20-Apr-87 1911 FAHLMAN@C.CS.CMU.EDU Issue: COMPILER-WARNING-STREAM (Revision 4)
C00533 00118 ∂21-Apr-87 0400 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Re: Bignums are bogus?
C00536 00119 ∂21-Apr-87 0747 FAHLMAN@C.CS.CMU.EDU Environment-Arguments
C00541 00120 ∂21-Apr-87 0814 Hvatum.DLAB@MIT-MULTICS.ARPA "Redefining" functions
C00545 00121 ∂21-Apr-87 0814 Hvatum.DLAB@MIT-MULTICS.ARPA Compiling CASE
C00551 00122 ∂21-Apr-87 0918 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT
C00554 00123 ∂21-Apr-87 0919 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FLET-IMPLICIT-BLOCK (Revision 5)
C00556 00124 ∂21-Apr-87 0920 Moon@STONY-BROOK.SCRC.Symbolics.COM Environment-Arguments
C00564 00125 ∂21-Apr-87 0921 KMP@STONY-BROOK.SCRC.Symbolics.COM IF-BODY
C00567 00126 ∂21-Apr-87 1051 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00571 00127 ∂21-Apr-87 1155 Moon@STONY-BROOK.SCRC.Symbolics.COM Environment-Arguments
C00573 00128 ∂21-Apr-87 1215 FAHLMAN@C.CS.CMU.EDU IF-BODY
C00575 00129 ∂21-Apr-87 1222 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00578 00130 ∂21-Apr-87 1253 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00580 00131 ∂21-Apr-87 1303 goldman@vaxa.isi.edu MULTIPLE-VALUES, consing, and clarity
C00584 00132 ∂21-Apr-87 1425 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM MULTIPLE-VALUES, consing, and clarity
C00586 00133 ∂21-Apr-87 1506 Pavel.pa@Xerox.COM Re: MULTIPLE-VALUES, consing, and clarity
C00588 00134 ∂21-Apr-87 1450 Pavel.pa@Xerox.COM [Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:
C00593 00135 ∂21-Apr-87 1655 Moon@STONY-BROOK.SCRC.Symbolics.COM MULTIPLE-VALUES, consing, and clarity
C00595 00136 ∂21-Apr-87 1659 Moon@STONY-BROOK.SCRC.Symbolics.COM [Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:
C00598 00137 ∂21-Apr-87 2309 MURRAY%cs.umass.edu@RELAY.CS.NET MULTPLE-VALUE-OR &rest args
C00605 00138 ∂22-Apr-87 1116 rauen@CLS.LCS.MIT.EDU Streams
C00607 00139 ∂22-Apr-87 1232 KMP@STONY-BROOK.SCRC.Symbolics.COM ASSOC-RASSOC-IF-KEY (Version 1)
C00611 00140 ∂22-Apr-87 1343 KMP@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
C00616 00141 ∂22-Apr-87 1351 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-NOT-ADJUSTABLE
C00623 00142 ∂22-Apr-87 2307 Moon@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
C00629 00143 ∂23-Apr-87 1205 smith@nrl-aic.ARPA A simple question
C00631 00144 ∂23-Apr-87 1250 Moon@STONY-BROOK.SCRC.Symbolics.COM A simple question
C00633 00145 ∂23-Apr-87 1255 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM A simple question
C00636 00146 ∂23-Apr-87 1313 REM@IMSSS Just for fun (NULL of NULL is identity)
C00638 00147 ∂23-Apr-87 1822 RWK@YUKON.SCRC.Symbolics.COM A simple question
C00641 00148 ∂23-Apr-87 1858 KMP@STONY-BROOK.SCRC.Symbolics.COM A simple question
C00646 00149 ∂23-Apr-87 2022 RWK@YUKON.SCRC.Symbolics.COM Streams
C00649 00150 ∂23-Apr-87 2338 edsel!bhopal!jonl@navajo.stanford.edu A simple question
C00651 00151 ∂24-Apr-87 0741 decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM Mailing List
C00653 00152 ∂24-Apr-87 0752 smith@nrl-aic.ARPA Re: A simple question
C00655 00153 ∂24-Apr-87 0843 DALY@IBM.COM CLtL typos list
C00657 00154 ∂24-Apr-87 2307 coffee@aerospace.aero.org Re: A simple question
C00660 00155 ∂25-Apr-87 0052 VERACSD@A.ISI.EDU Pronunciation
C00661 00156 ∂25-Apr-87 2132 @po5.andrew.cmu.edu:zs01#@andrew.cmu.edu Re: Pronunciation
C00663 00157 ∂25-Apr-87 2341 KMP@STONY-BROOK.SCRC.Symbolics.COM Pronunciation
C00665 00158 ∂27-Apr-87 1008 unido!gmdzi!LISPM-1.GMD!@lispm-1.gmd.jc Pronunciation
C00668 00159 ∂27-Apr-87 1110 Moon@STONY-BROOK.SCRC.Symbolics.COM MULTPLE-VALUE-OR &rest args
C00672 00160 ∂27-Apr-87 1119 coffee@aerospace.aero.org Cleaning up predicate returns
C00677 00161 ∂27-Apr-87 1206 larus@paris.Berkeley.EDU (reduce #'or ...)
C00679 00162 ∂27-Apr-87 1338 quiroz@rochester.arpa Re: (reduce #'or ...)
C00682 00163 ∂27-Apr-87 1340 coffee@aerospace.aero.org Very BIG "T"
C00684 00164 ∂27-Apr-87 1517 Mailer@XX.LCS.MIT.EDU (reduce #'or ...)
C00687 00165 ∂28-Apr-87 2212 MURRAY%cs.umass.edu@RELAY.CS.NET MULTIPLE-VALUES OR
C00691 00166 ∂28-Apr-87 2240 MURRAY%cs.umass.edu@RELAY.CS.NET (REDUCE #'OVERHEAD (MAP ...))
C00695 00167 ∂29-Apr-87 1407 gls@Think.COM CLtL typos list
C00698 00168 ∂30-Apr-87 1113 @ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU (REDUCE #'OVERHEAD (MAP ...))
C00700 00169 ∂30-Apr-87 1355 FAHLMAN@C.CS.CMU.EDU Notice on Kyoto Common Lisp distribution
C00703 00170 ∂01-May-87 1440 EMAILDEV%UKACRL.BITNET@BERKELEY.EDU Notice on Kyoto Common Lisp distribution
C00705 00171 ∂05-May-87 1825 FAHLMAN@C.CS.CMU.EDU Kyoto Common Lisp addendum
C00710 00172 ∂08-May-87 1725 kempf%hplabsc@hplabs.HP.COM Rule System in CommonLoops/CLOS
C00712 00173 ∂09-May-87 0501 TMB%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Smalltalk-80 Classes for Symbolics and/or CommonLisp
C00714 00174 ∂12-May-87 0301 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU atom type question
C00715 00175 ∂12-May-87 0637 FAHLMAN@C.CS.CMU.EDU atom type question
C00717 00176 ∂12-May-87 0715 RAM@C.CS.CMU.EDU atom type question
C00720 00177 ∂12-May-87 1753 RWK@YUKON.SCRC.Symbolics.COM atom type question
C00725 00178 ∂13-May-87 1426 berman@vaxa.isi.edu &REST
C00729 00179 ∂13-May-87 1512 DLW@ALDERAAN.SCRC.Symbolics.COM &REST
C00731 00180 ∂14-May-87 0913 coffee@aerospace.aero.org Re: &REST
C00734 00181 ∂14-May-87 1107 berman@vaxa.isi.edu Re: &REST
C00736 00182 ∂14-May-87 1314 coffee@aerospace.aero.org Re: Gold Hill's floating-point
C00738 00183 ∂14-May-87 1438 berman@vaxa.isi.edu documentation
C00741 00184 ∂14-May-87 1507 edsel!bhopal!jonl@navajo.stanford.edu Re: &REST
C00744 00185 ∂14-May-87 1724 FAHLMAN@C.CS.CMU.EDU documentation
C00746 00186 ∂15-May-87 1035 coffee@aerospace.aero.org Re: Gold Hill's floating-point
C00752 00187 ∂15-May-87 1331 @ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU (REDUCE #'OVERHEAD (MAP ...))
C00757 00188 ∂15-May-87 1333 Mailer@XX.LCS.MIT.EDU Re: &REST
C00760 00189 ∂15-May-87 1403 ACUFF@SUMEX-AIM.STANFORD.EDU Re: &REST
C00762 00190 ∂15-May-87 1747 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU Last message to list.
C00764 00191 ∂17-May-87 1532 dg%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: &REST
C00766 00192 ∂18-May-87 0603 dml@nadc Addition to mailing list.
C00767 00193 ∂18-May-87 0811 FAHLMAN@C.CS.CMU.EDU Mailing List for Lucid Users
C00771 00194 ∂18-May-87 1151 @RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET Introduction to a multi-byte character extension
C00777 00195 ∂18-May-87 1158 @RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET A multi-byte character extension proposal
C00819 00196 ∂18-May-87 1547 berman@vaxa.isi.edu Format
C00822 00197 ∂18-May-87 1719 barmar@Think.COM Format
C00825 00198 ∂18-May-87 1736 Olasov.StudentNS@MIT-Multics.ARPA Communications packages in Common LISP
C00827 00199 ∂18-May-87 2222 @RELAY.CS.NET:MURRAY@cs.umass.edu User-Visible Declarations and Proclamations
C00831 00200 ∂19-May-87 1136 Moon@STONY-BROOK.SCRC.Symbolics.COM User-Visible Declarations and Proclamations
C00835 00201 ∂19-May-87 1139 berman@vaxa.isi.edu ~% Directive
C00837 00202 ∂19-May-87 1220 FAHLMAN@C.CS.CMU.EDU ~% Directive
C00840 00203 ∂19-May-87 1347 berman@vaxa.isi.edu More FORMAT
C00844 00204 ∂19-May-87 1511 Moon@STONY-BROOK.SCRC.Symbolics.COM More FORMAT
C00847 00205 ∂19-May-87 1524 berman@vaxa.isi.edu Re: More FORMAT
C00850 00206 ∂19-May-87 1608 barmar@Think.COM Re: More FORMAT
C00854 00207 ∂19-May-87 1618 Daniels.pa@Xerox.COM Re: More FORMAT
C00858 00208 ∂19-May-87 1802 sandra%orion@cs.utah.edu All arrays can be adjustable?
C00863 00209 ∂19-May-87 1835 Moon@STONY-BROOK.SCRC.Symbolics.COM All arrays can be adjustable?
C00868 00210 ∂19-May-87 2000 DLA@DIAMOND.S4CC.Symbolics.COM All arrays can be adjustable?
C00870 00211 ∂19-May-87 2000 @DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM All arrays can be adjustable?
C00874 00212 ∂19-May-87 2342 KMP@STONY-BROOK.SCRC.Symbolics.COM adjustable arrays
C00878 00213 ∂20-May-87 0248 Mailer@XX.LCS.MIT.EDU Re: More FORMAT
C00880 00214 ∂20-May-87 0635 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM All arrays can be adjustable?
C00883 00215 ∂20-May-87 0836 DLW@ALDERAAN.SCRC.Symbolics.COM Re: More FORMAT
C00886 00216 ∂20-May-87 0841 DLW@ALDERAAN.SCRC.Symbolics.COM All arrays can be adjustable?
C00890 00217 ∂20-May-87 0851 franz!ficl!jkf@ucbarpa.Berkeley.EDU adjustable arrays
C00893 00218 ∂20-May-87 0859 FAHLMAN@C.CS.CMU.EDU All arrays can be adjustable?
C00896 00219 ∂20-May-87 0955 @RELAY.CS.NET:DUSSUD%Jenner@TI-CSL.CSNET [dg%acorn@oak.lcs.mit.edu: Re: &REST]
C00900 00220 ∂20-May-87 1013 johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK
C00901 00221 ∂20-May-87 1039 las@bfly-vax.bbn.com
C00903 00222 ∂20-May-87 1123 barmar@Think.COM DISASSEMBLE, et all return values
C00905 00223 ∂20-May-87 1158 berman@vaxa.isi.edu Re: More FORMAT
C00907 00224 ∂20-May-87 1210 berman@vaxa.isi.edu
C00909 00225 ∂20-May-87 1239 berman@vaxa.isi.edu las@bfly-vax.bbn.com
C00910 00226 ∂20-May-87 1247 las@bfly-vax.bbn.com
C00913 00227 ∂20-May-87 1251 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM All arrays can be adjustable?
C00916 00228 ∂20-May-87 1359 peck@Sun.COM Order of evaluation in PUSH (& PUSHNEW)
C00920 00229 ∂20-May-87 1551 berman@vaxa.isi.edu :fill-pointer maybe
C00922 00230 ∂20-May-87 1623 berman@vaxa.isi.edu arrays
C00925 00231 ∂20-May-87 1647 FAHLMAN@C.CS.CMU.EDU :fill-pointer maybe
C00930 00232 ∂20-May-87 1658 FAHLMAN@C.CS.CMU.EDU arrays
C00933 00233 ∂20-May-87 1840 berman@vaxa.isi.edu arrays
C00936 00234 ∂20-May-87 1840 FAHLMAN@C.CS.CMU.EDU :fill-pointer maybe
C00941 00235 ∂20-May-87 1840 FAHLMAN@C.CS.CMU.EDU arrays
C00944 00236 ∂20-May-87 1844 Moon@STONY-BROOK.SCRC.Symbolics.COM Order of evaluation in PUSH (& PUSHNEW)
C00948 00237 ∂20-May-87 1844 Moon@STONY-BROOK.SCRC.Symbolics.COM arrays
C00952 00238 ∂20-May-87 1902 rauen@CLS.LCS.MIT.EDU Roman numeral hacking.
C00953 00239 ∂20-May-87 1911 ibuki!weaver@labrea.stanford.edu Order of evaluation in PUSH
C00955 00240 ∂20-May-87 1955 edsel!bhopal!jonl@navajo.stanford.edu [adjustable arrays?] More FORMAT
C00958 00241 ∂20-May-87 2037 quiroz@cs.rochester.edu Re: Order of evaluation in PUSH (& PUSHNEW)
C00963 00242 ∂20-May-87 2134 FAHLMAN@C.CS.CMU.EDU Order of evaluation in PUSH (& PUSHNEW)
C00966 00243 ∂20-May-87 2209 Mailer@XX.LCS.MIT.EDU [dg%acorn@oak.lcs.mit.edu: Re: &REST]
C00969 00244 ∂20-May-87 2254 edsel!bhopal!jonl@navajo.stanford.edu All arrays can be adjustable?
C00972 00245 ∂21-May-87 0556 @diamond.s4cc.symbolics.com,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM [adjustable arrays?] More FORMAT
C00976 00246 ∂21-May-87 0725 DALY@IBM.COM validation suite
C00977 00247 ∂21-May-87 0938 moss!tk@harvard.harvard.edu Re: Notice on Kyoto Common Lisp distribution (query)
C00979 00248 ∂21-May-87 0945 larus%paris.Berkeley.EDU@Berkeley.EDU Re: Order of evaluation in PUSH (& PUSHNEW)
C00982 00249 ∂21-May-87 1019 DLW@ALDERAAN.SCRC.Symbolics.COM [adjustable arrays?] More FORMAT
C00984 00250 ∂21-May-87 1124 @DIAMOND.S4CC.Symbolics.COM:PTW@YUKON.SCRC.Symbolics.COM Re: Order of evaluation in PUSH (& PUSHNEW)
C00986 00251 ∂21-May-87 1148 berman@vaxa.isi.edu Re: :fill-pointer maybe
C00988 00252 ∂21-May-87 1156 berman@vaxa.isi.edu Re: validation suite
C00990 00253 ∂21-May-87 1220 FAHLMAN@C.CS.CMU.EDU :fill-pointer maybe
C00992 00254 ∂21-May-87 1323 Mailer@xx.lcs.mit.edu All arrays can be adjustable?
C00995 00255 ∂21-May-87 1347 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Order of evaluation in PUSH (& PUSHNEW)
C00998 00256 ∂21-May-87 1411 larus%paris.Berkeley.EDU@Berkeley.EDU Re: Order of evaluation in PUSH (& PUSHNEW)
C01004 00257 ∂22-May-87 0152 Randy%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: Order of evaluation in general
C01007 00258 ∂22-May-87 0718 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Order of evaluation in general
C01010 00259 ∂22-May-87 0729 gls@Think.COM All arrays can be adjustable?
C01013 00260 ∂22-May-87 0748 gls@Think.COM Re: More FORMAT
C01016 00261 ∂22-May-87 0801 gls@Think.COM numerals, Roman, large, overly, printing of, how to do it
C01018 00262 ∂22-May-87 0815 FAHLMAN@C.CS.CMU.EDU numerals, Roman, large, overly, printing of, how to do it
C01020 00263 ∂22-May-87 1257 berman@vaxa.isi.edu :KEY, hairsplit
C01024 00264 ∂22-May-87 1449 primerd!doug@enx.prime.pdn
C01028 00265 ∂22-May-87 1609 DLW@ALDERAAN.SCRC.Symbolics.COM defsystem
C01031 00266 ∂25-May-87 0459 GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU All arrays can be adjustable?
C01033 00267 ∂25-May-87 1032 primerd!doug@enx.prime.pdn Revision 2.1 of public defsystem available
C01035 00268 ∂01-Jun-87 0840 DALY@IBM.COM type specifiers
C01037 00269 ∂01-Jun-87 1929 RWK@YUKON.SCRC.Symbolics.COM type specifiers
C01041 00270 ∂03-Jun-87 0739 Mailer@XX.LCS.MIT.EDU SIMPLE-VECTOR
C01046 00271 ∂03-Jun-87 1004 gls@Think.COM Latin
C01048 00272 ∂03-Jun-87 1505 RWK@YUKON.SCRC.Symbolics.COM SIMPLE-VECTOR
C01052 00273 ∂03-Jun-87 1856 Moon@STONY-BROOK.SCRC.Symbolics.COM SIMPLE-VECTOR
C01055 00274 ∂04-Jun-87 0802 RAM@C.CS.CMU.EDU SIMPLE-VECTOR
C01057 00275 ∂04-Jun-87 1425 RWK@ELEPHANT-BUTTE.SCRC.Symbolics.COM SIMPLE-VECTOR
C01059 00276 ∂04-Jun-87 2350 @Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com Interpretation Needed for #+feature
C01062 00277 ∂05-Jun-87 0734 samalone@ATHENA.MIT.EDU Re: Interpretation Needed for #+feature
C01064 00278 ∂05-Jun-87 1017 sandra%orion@cs.utah.edu historical question about CASE
C01066 00279 ∂05-Jun-87 1019 RPG JIS LISP WG of this year
C01069 00280 ∂05-Jun-87 1020 RPG Re: JIS LISP WG of this year
C01071 00281 ∂05-Jun-87 1142 barmar@Think.COM historical question about CASE
C01075 00282 ∂05-Jun-87 1313 SOLEY@XX.LCS.MIT.EDU historical question about CASE
C01078 00283 ∂05-Jun-87 1400 gls@Think.COM historical question about CASE
C01082 00284 ∂05-Jun-87 1400 barmar@Think.COM historical question about CASE
C01084 00285 ∂10-Jun-87 0755 dml@NADC.ARPA Common LISP omissions: Collect, Locatives
C01089 00286 ∂10-Jun-87 0837 FAHLMAN@C.CS.CMU.EDU Common LISP omissions: Collect, Locatives
C01092 00287 ∂10-Jun-87 1101 hoey@nrl-aic.ARPA LISP:STRUCTURE ?
C01094 00288 ∂10-Jun-87 1120 RAM@C.CS.CMU.EDU LISP:STRUCTURE ?
C01096 00289 ∂10-Jun-87 1121 KMP@STONY-BROOK.SCRC.Symbolics.COM LISP:STRUCTURE
C01098 00290 ∂10-Jun-87 1238 DALY@IBM.COM locatives...
C01100 00291 ∂10-Jun-87 1415 Moon@VALLECITO.SCRC.Symbolics.COM Common LISP omissions: Locatives
C01108 00292 ∂11-Jun-87 1313 gls@Think.COM Re: historical question about CASE
C01111 00293 ∂12-Jun-87 1022 dml@NADC.ARPA Hash-on-eq
C01113 00294 ∂22-Jun-87 0422 fritzson@bigburd.PRC.Unisys.COM APPLY with 3+ arguments
C01115 00295 ∂22-Jun-87 0601 dml@NADC.ARPA Re: APPLY with 3+ arguments
C01117 00296 ∂22-Jun-87 0654 @RELAY.CS.NET:kers@HPLB.CSNET I Like a Single Namespace
C01129 00297 ∂22-Jun-87 0655 samalone@ATHENA.MIT.EDU Re: APPLY with 3+ arguments
C01132 00298 ∂22-Jun-87 0741 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM APPLY with 3+ arguments
C01135 00299 ∂22-Jun-87 0959 barmar@Think.COM I Like a Single Namespace
C01138 00300 ∂22-Jun-87 1359 Daniels.pa@Xerox.COM Re: APPLY with 3+ arguments
C01140 00301 ∂22-Jun-87 1457 Daniels.pa@Xerox.COM Re: APPLY with 3+ arguments
C01142 00302 ∂23-Jun-87 0252 @RELAY.CS.NET:kers@HPLB.CSNET
C01144 00303 ∂23-Jun-87 0654 CL.BOYER@R20.UTEXAS.EDU Kyoto Common Lisp
C01168 00304 ∂23-Jun-87 1535 BAGGINS@IBM.COM A multi-byte character extension proposal
C01177 00305 ∂25-Jun-87 0923 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
C01187 00306 ∂25-Jun-87 1028 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
C01197 00307 ∂25-Jun-87 1143 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
C01207 00308 ∂25-Jun-87 1255 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
C01217 00309 ∂25-Jun-87 1505 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
C01227 00310 ∂25-Jun-87 1626 Cassels@STONY-BROOK.SCRC.Symbolics.COM Format ~E nit -- language lawyer sought
C01229 00311 ∂26-Jun-87 1911 VERACSD@A.ISI.EDU MODIFYF
C01232 00312 ∂26-Jun-87 2250 @RELAY.CS.NET:CORK@cs.umass.edu Tracing locally defined functions
C01238 00313 ∂27-Jun-87 1337 sandra%orion@cs.utah.edu print question
C01241 00314 ∂28-Jun-87 1146 edsel!bhopal!jonl@navajo.stanford.edu print question
C01244 00315 ∂28-Jun-87 1801 RWK@YUKON.SCRC.Symbolics.COM Tracing locally defined functions
C01249 00316 ∂29-Jun-87 0707 dml@NADC.ARPA Re: MODIFYF
C01252 00317 ∂29-Jun-87 1031 Mailer@xx.lcs.mit.edu print question
C01255 00318 ∂29-Jun-87 2210 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
C01269 00319 ∂30-Jun-87 1021 @RELAY.CS.NET:HASSETT@sp.unisys.com 2 namespaces & a complement to #' notation
C01275 00320 ∂01-Jul-87 0742 @Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com Flavors for KCL
C01277 00321 ∂02-Jul-87 0534 mab@mind.Princeton.EDU Loop Macro (after Zetalisp, franz, etc.)
C01279 00322 ∂02-Jul-87 0812 mab@flash.bellcore.com Loop Macro (after Zetalisp, Franz, etc.)
C01281 00323 ∂02-Jul-87 0911 kempf%hplabsc@hplabs.HP.COM Location of defsys.l?
C01283 00324 ∂02-Jul-87 1355 @RELAY.CS.NET:GREENBERG@cs.umass.edu Questions about (function eq)
C01286 00325 ∂02-Jul-87 1510 barmar@Think.COM Questions about (function eq)
C01294 00326 ∂02-Jul-87 1643 primerd!enx!doug@EDDIE.MIT.EDU
C01297 00327 ∂02-Jul-87 1651 jeff%JASPER.Palladian.COM@XX.LCS.MIT.EDU Loop Macro (after Zetalisp, Franz, etc.)
C01303 00328 ∂06-Jul-87 0937 @Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com Atoms in association lists
C01306 00329 ∂06-Jul-87 1838 OKUNO@SUMEX-AIM.STANFORD.EDU Re: Flavors for KCL
C01308 00330 ∂07-Jul-87 0918 KMP@STONY-BROOK.SCRC.Symbolics.COM Atoms in association lists
C01316 00331 ∂07-Jul-87 1902 OKUNO@SUMEX-AIM.STANFORD.EDU Re: Flavors for KCL
C01318 00332 ∂08-Jul-87 0938 coffee@aerospace.aero.org Re: Atoms in association lists
C01321 00333 ∂08-Jul-87 1224 dml@NADC.ARPA Re: Atoms in association lists
C01323 00334 ∂08-Jul-87 1448 Daniels.pa@Xerox.COM Re: Atoms in association lists
C01325 00335 ∂08-Jul-87 2038 edsel!bhopal!jonl@navajo.stanford.edu print question
C01327 00336 ∂08-Jul-87 2202 edsel!bhopal!jonl@navajo.stanford.edu Loop Macro (after Zetalisp, franz, etc.)
C01329 00337 ∂09-Jul-87 0358 sidney%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Atoms in association lists
C01331 00338 ∂09-Jul-87 0359 sidney%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: Atoms in association lists
C01334 00339 ∂09-Jul-87 0452 @DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM Re: Atoms in association lists
C01337 00340 ∂09-Jul-87 0521 thoms@caen.engin.umich.edu OPS5
C01339 00341 ∂09-Jul-87 0546 dml@NADC.ARPA Re: Atoms in association lists
C01341 00342 ∂09-Jul-87 0621 dml@NADC.ARPA Plists and NIL.
C01343 00343 ∂09-Jul-87 0919 johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK kcl
C01345 00344 ∂09-Jul-87 0930 @RELAY.CS.NET:hagiya%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Re: Flavors for KCL
C01349 00345 ∂09-Jul-87 1118 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK UK KCL
C01351 00346 ∂09-Jul-87 1207 AI.BOYER@MCC.COM Re: kcl
C01352 00347 ∂09-Jul-87 1207 Daniels.pa@Xerox.COM Re: Plists and NIL.
C01354 00348 ∂09-Jul-87 1208 vax135!lcuxle!elia@ucbvax.Berkeley.EDU macrolet
C01357 00349 ∂09-Jul-87 1404 berman@vaxa.isi.edu Validation suite
C01360 00350 ∂09-Jul-87 1856 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Plists and NIL.
C01363 00351 ∂10-Jul-87 0809 sandra%orion@cs.utah.edu special forms
C01365 00352 ∂10-Jul-87 0942 RAM@C.CS.CMU.EDU special forms
C01368 00353 ∂10-Jul-87 1116 KMP@STONY-BROOK.SCRC.Symbolics.COM Appropriate use of the Common-Lisp mailing list
C01372 00354 ∂10-Jul-87 1116 KMP@STONY-BROOK.SCRC.Symbolics.COM macrolet
C01378 00355 ∂10-Jul-87 1127 KMP@STONY-BROOK.SCRC.Symbolics.COM Plists and NIL.
C01385 00356 ∂14-Jul-87 0816 kempf%hplabsz@hplabs.HP.COM Re: Appropriate use of the Common-Lisp mailing list
C01389 00357 ∂14-Jul-87 0922 skh@spice.cs.cmu.edu Apropos case sensitive?
C01391 00358 ∂14-Jul-87 0929 @MCC.COM:root%bell.cad.mcc.com@mcc.com Test - Please ignore
C01392 00359 ∂14-Jul-87 1946 vrotney@venera.isi.edu Re: Apropos case sensitive?
C01396 00360 ∂15-Jul-87 2313 @RELAY.CS.NET:HELLER@cs.umass.edu RE: Apropos case sensitive?
C01400 00361 ∂16-Jul-87 0624 kanya@caen.engin.umich.edu Prolog
C01402 00362 ∂16-Jul-87 1123 DALY@IBM.COM pathnames, portability, ed, eval-when, compile-file, fasl files
C01407 00363 ∂16-Jul-87 1609 RAM@C.CS.CMU.EDU editor issues
C01412 00364 ∂16-Jul-87 1630 RAM@C.CS.CMU.EDU eval-when issues
C01418 00365 ∂17-Jul-87 1026 edsel!bhopal!jonl@labrea.stanford.edu Appropriate use of the Common-Lisp mailing list
C01422 00366 ∂20-Jul-87 1132 Kahn.pa@Xerox.COM Re: Prolog
C01424 00367 ∂20-Jul-87 2130 edsel!bhopal!jonl@labrea.stanford.edu Apropos case sensitive?
C01429 00368 ∂22-Jul-87 0715 EJS%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: Atoms in association lists
C01434 00369 ∂23-Jul-87 1222 VERACSD@A.ISI.EDU Toplevel lexical variables
C01438 00370 ∂23-Jul-87 1509 pierson@multimax.ARPA Toplevel lexical variables
C01440 00371 ∂23-Jul-87 1739 VERACSD@A.ISI.EDU Correction
C01443 00372 ∂24-Jul-87 0806 SWM@SAPSUCKER.SCRC.Symbolics.COM Correction
C01446 00373 ∂24-Jul-87 0939 Gregor.pa@Xerox.COM Re: Correction
C01449 00374 ∂24-Jul-87 1020 SWM@SAPSUCKER.SCRC.Symbolics.COM Re: Correction
C01453 00375 ∂24-Jul-87 1043 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Correction
C01455 00376 ∂24-Jul-87 1218 barmar@think.com Re: Correction
C01458 00377 ∂25-Jul-87 2249 @RELAY.CS.NET:MURRAY@cs.umass.edu EOF-VALUE
C01461 00378 ∂26-Jul-87 1433 smh@EMS.MEDIA.MIT.EDU Re: EOF-VALUE
C01463 00379 ∂26-Jul-87 1623 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU EOF-VALUE
C01467 00380 ∂27-Jul-87 0949 barmar@think.com EOF-VALUE
C01470 00381 ∂27-Jul-87 1423 gls@Think.COM EOF-VALUE
C01472 00382 ∂27-Jul-87 1447 SCHMIDT@SUMEX-AIM.STANFORD.EDU Re: Toplevel lexical variables
C01474 00383 ∂27-Jul-87 1706 pierson@multimax.ARPA Toplevel lexical variables
C01476 00384 ∂28-Jul-87 0050 wade@wombat.stanford.edu EOF value
C01477 00385 ∂29-Jul-87 0039 @RELAY.CS.NET:MURRAY@cs.umass.edu *eof-value*
C01480 00386 ∂29-Jul-87 0648 smh@EMS.MEDIA.MIT.EDU Re: *eof-value*
C01484 00387 ∂31-Jul-87 1455 wile@vaxa.isi.edu Test Suite availability
C01488 00388 ∂31-Jul-87 2159 sandra%orion@cs.utah.edu compile-time processing of REQUIRE
C01491 00389 ∂01-Aug-87 1031 smh@EMS.MEDIA.MIT.EDU Re: compile-time processing of REQUIRE
C01493 00390 ∂02-Aug-87 0808 edsel!bhopal!jonl@labrea.stanford.edu compile-time processing of REQUIRE
C01500 00391 ∂03-Aug-87 0907 barmar@Think.COM New special form suggestion: LET-CONSTANT
C01503 00392 ∂03-Aug-87 0930 samalone@ATHENA.MIT.EDU Re: New special form suggestion: LET-CONSTANT
C01505 00393 ∂03-Aug-87 1021 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM New special form suggestion: LET-CONSTANT
C01508 00394 ∂03-Aug-87 1023 snyder%hplsny@hplabs.HP.COM Re: compile-time processing of REQUIRE
C01511 00395 ∂03-Aug-87 1041 RpK%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Question on function type spec and lambda-list keywords
C01513 00396 ∂03-Aug-87 1211 edsel!kent-state!eb@labrea.stanford.edu New special form suggestion: LET-CONSTANT
C01516 00397 ∂03-Aug-87 1315 vanroggen%aitg.decnet@hudson.dec.com LET-CONSTANT and DECLARE (CONSTANT
C01518 00398 ∂03-Aug-87 1317 Moon@SAPSUCKER.SCRC.Symbolics.COM New special form suggestion: LET-CONSTANT
C01521 00399 ∂03-Aug-87 1340 RAM@C.CS.CMU.EDU LET-CONSTANT and DECLARE (CONSTANT
C01523 00400 ∂03-Aug-87 1352 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU New special form suggestion: LET-CONSTANT
C01527 00401 ∂03-Aug-87 1427 barmar@Think.COM New special form suggestion: LET-CONSTANT
C01531 00402 ∂03-Aug-87 1658 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: New special form suggestion: LET-CONSTANT
C01534 00403 ∂03-Aug-87 2039 edsel!bhopal!jonl@labrea.stanford.edu compile-time processing of REQUIRE
C01537 00404 ∂03-Aug-87 2317 edsel!bhopal!jonl@labrea.stanford.edu LET-CONSTANT [or "Anonymous Constants"]
C01542 00405 ∂04-Aug-87 1057 @DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM New special form suggestion: LET-CONSTANT
C01546 00406 ∂06-Aug-87 0721 SOLEY@XX.LCS.MIT.EDU New special form suggestion: LET-CONSTANT
C01549 00407 ∂06-Aug-87 0809 gls@Think.COM New special form suggestion: LET-CONSTANT
C01553 00408 ∂06-Aug-87 1308 sandra%orion@cs.utah.edu truename, merge-pathnames, etc.
C01556 00409 ∂06-Aug-87 1612 RWK@YUKON.SCRC.Symbolics.COM truename, merge-pathnames, etc.
C01561 00410 ∂07-Aug-87 2215 @RELAY.CS.NET:HELLER@cs.umass.edu RE: truename, merge-pathnames, etc.
C01567 00411 ∂08-Aug-87 0858 sandra%orion@cs.utah.edu RE: truename, merge-pathnames, etc.
C01570 00412 ∂08-Aug-87 1347 RAM@C.CS.CMU.EDU truename, merge-pathnames, etc.
C01574 00413 ∂09-Aug-87 1439 tsf@theory.cs.cmu.edu Continuation Passing Style?
C01576 00414 ∂10-Aug-87 1216 wile@vaxa.isi.edu Test suite available
C01580 00415 ∂17-Aug-87 0054 GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU FLET & declarations
C01582 00416 ∂18-Aug-87 0902 mike%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Question on function type spec and lambda-list keywords
C01585 00417 ∂18-Aug-87 1328 Moon@STONY-BROOK.SCRC.Symbolics.COM FLET & declarations
C01589 00418 ∂24-Aug-87 0628 unido!ztivax!kolb@seismo.CSS.GOV Interpretation of shadowing
C01593 00419 ∂24-Aug-87 0753 samalone@ATHENA.MIT.EDU Re: Interpretation of shadowing
C01598 00420 ∂24-Aug-87 1111 Moon@STONY-BROOK.SCRC.Symbolics.COM Interpretation of shadowing
C01600 00421 ∂24-Aug-87 1123 dml@NADC.ARPA The values returned by SETF
C01602 00422 ∂24-Aug-87 1148 Moon@STONY-BROOK.SCRC.Symbolics.COM The values returned by SETF
C01604 00423 ∂24-Aug-87 1204 093725%incdp1@LANL.GOV New Address for Common Lisp
C01606 00424 ∂24-Aug-87 1310 Pavel.pa@Xerox.COM Re: The values returned by SETF
C01608 00425 ∂25-Aug-87 0713 RAM@C.CS.CMU.EDU The values returned by SETF
C01611 00426 ∂25-Aug-87 1201 edsel!bhopal!jonl@labrea.stanford.edu Interpretation of shadowing [and type of argument to SHADOW]
C01618 00427 ∂25-Aug-87 1354 Moon@STONY-BROOK.SCRC.Symbolics.COM Interpretation of shadowing [and type of argument to SHADOW]
C01621 00428 ∂25-Aug-87 1527 @DOUGHNUT.CS.ROCHESTER.EDU:miller@DOUGHNUT.CS.ROCHESTER.EDU SHADOW et. al
C01625 00429 ∂27-Aug-87 1239 DALY@IBM.COM length
C01628 00430 ∂27-Aug-87 1344 Moon@STONY-BROOK.SCRC.Symbolics.COM The values returned by SETF
C01632 00431 ∂28-Aug-87 0718 decvax!cvbnet!expert!pmorris@decwrl.dec.com New Reader
C01634 00432 ∂28-Aug-87 0849 sandra%orion@cs.utah.edu cleanup status?
C01636 00433 ∂28-Aug-87 0916 edsel!bhopal!jonl@labrea.stanford.edu length
C01639 00434 ∂28-Aug-87 1246 KMP@STONY-BROOK.SCRC.Symbolics.COM length
C01647 00435 ∂28-Aug-87 1645 edsel!bhopal!jonl@labrea.stanford.edu length
C01649 00436 ∂28-Aug-87 1702 KMP@STONY-BROOK.SCRC.Symbolics.COM length
C01653 00437 ∂29-Aug-87 1618 Masinter.pa@Xerox.COM Re: cleanup status?
C01656 00438 ∂03-Sep-87 2119 GINN@sumex-aim.stanford.edu Common Lisp LOOP
C01658 00439 ∂04-Sep-87 1052 Moon@STONY-BROOK.SCRC.Symbolics.COM Common Lisp LOOP
C01660 00440 ∂05-Sep-87 1031 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Re: Common Lisp LOOP
C01699 00441 ∂07-Sep-87 0829 LINNDR%VUENGVAX.BITNET@forsythe.stanford.edu KCL LOOP posting
C01701 00442 ∂07-Sep-87 1014 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK KCL LOOP posting
C01703 00443 ∂09-Sep-87 0803 DALY@IBM.COM setf order of evaluation
C01705 00444 ∂09-Sep-87 1139 Moon@STONY-BROOK.SCRC.Symbolics.COM setf order of evaluation
C01709 00445 ∂10-Sep-87 0741 NGALL@G.BBN.COM Re: setf order of evaluation
C01713 00446 ∂10-Sep-87 1824 raible@orville.nas.nasa.gov Re: Common Lisp LOOP
C01715 00447 ∂10-Sep-87 1919 franz!ficl!drb@ucbarpa.Berkeley.EDU setf order of evaluation
C01720 00448 ∂10-Sep-87 2013 KMP@STONY-BROOK.SCRC.Symbolics.COM setf order of evaluation
C01726 00449 ∂11-Sep-87 1144 Moon@STONY-BROOK.SCRC.Symbolics.COM setf order of evaluation
C01731 00450 ∂11-Sep-87 2240 @RELAY.CS.NET:HELLER@cs.umass.edu RE: setf order of evaluation
C01736 00451 ∂18-Sep-87 1143 gls@Think.COM [KAHLE@Aquinas.Think.COM: defstruct request for common lisp]
C01738 00452 ∂18-Sep-87 1234 gls@Think.COM [KAHLE@Aquinas.Think.COM: common lisp question]
C01741 00453 ∂21-Sep-87 0657 DLW@ALDERAAN.SCRC.Symbolics.COM [KAHLE@Aquinas.Think.COM: defstruct request for common lisp]
C01744 00454 ∂21-Sep-87 0701 DLW@ALDERAAN.SCRC.Symbolics.COM [KAHLE@Aquinas.Think.COM: common lisp question]
C01748 00455 ∂21-Sep-87 1410 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: setf order of evaluation
C01752 00456 ∂22-Sep-87 1359 KARSAIG1%VUENGVAX.BITNET@forsythe.stanford.edu BBS
C01754 00457 ∂23-Sep-87 0059 shebs%orion@cs.utah.edu Bigger Benchmarks
C01756 00458 ∂23-Sep-87 0059 newman.pasa@Xerox.COM Common Lisp 3270 emulation available?
C01758 00459 ∂23-Sep-87 1111 NGALL@G.BBN.COM Re: [KAHLE@Aquinas.Think.COM: common lisp question]
C01762 00460 ∂23-Sep-87 2013 @RELAY.CS.NET:DON@atc.bendix.com Synonym streams
C01765 00461 ∂23-Sep-87 2207 NGALL@G.BBN.COM Re: setf order of evaluation
C01771 00462 ∂24-Sep-87 0312 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Japanese Activities toward Lisp Standardization
C01779 00463 ∂24-Sep-87 1210 Masinter.pa@Xerox.COM STREAM-CLASS-ACCESS
C01784 00464 ∂24-Sep-87 1631 RWK@YUKON.SCRC.Symbolics.COM Synonym streams
C01788 00465 ∂25-Sep-87 0930 @BCO-MULTICS.ARPA:Dickson.Multics@HIS-PHOENIX-MULTICS.ARPA Please add us to you mailing list
C01790 00466 ∂27-Sep-87 1423 kempf%hplabsz@hplabs.HP.COM Re: STREAM-CLASS-ACCESS
C01792 00467 ∂28-Sep-87 1112 Masinter.pa@Xerox.COM Re: Japanese Activities toward Lisp Standardization
C01795 00468 ∂29-Sep-87 1349 @BCO-MULTICS.ARPA:May.KBS@HIS-PHOENIX-MULTICS.ARPA New Member Questions
C01797 00469 ∂30-Sep-87 1350 ghenis.pasa@Xerox.COM Source code non-access (Re: defstruct request)
C01799 00470 ∂01-Oct-87 0802 FAHLMAN@C.CS.CMU.EDU Source code non-access (Re: defstruct request)
C01804 00471 ∂01-Oct-87 1816 ghenis.pasa@Xerox.COM Re: [KAHLE@Aquinas.Think.COM: defstruct request for common
C01810 00472 ∂01-Oct-87 2025 sandra%orion@cs.utah.edu defstruct slot info
C01814 00473 ∂02-Oct-87 0502 barmar@Think.COM Re: [KAHLE@Aquinas.Think.COM: defstruct request for common
C01817 00474 ∂02-Oct-87 1033 ghenis.pasa@Xerox.COM Re: [KAHLE@Aquinas.Think.COM: defstruct request for common
C01819 00475 ∂05-Oct-87 1141 vgordon@venera.isi.edu CMU Common Lisp Distribution
C01829 00476 ∂05-Oct-87 1223 vgordon@venera.isi.edu CMU Common Lisp Distribution
C01839 00477 ∂05-Oct-87 1327 vgordon@venera.isi.edu CMU Common Lisp Distribution
C01849 00478 ∂05-Oct-87 1337 vgordon@venera.isi.edu CMU Common Lisp Distribution
C01859 00479 ∂05-Oct-87 2308 ME SAIL domain mailer test
C01860 00480 ∂06-Oct-87 0122 pyrnj!pyramid!bein@RUTGERS.EDU multiple-value-bind pervasive-ness ...
C01863 00481 ∂06-Oct-87 2305 @RELAY.CS.NET:GALLAGHER@cs.umass.edu Extending Defstruct
C01869 00482 ∂06-Oct-87 2306 @RELAY.CS.NET:GALLAGHER@cs.umass.edu Defstruct and CLOS
C01872 00483 ∂06-Oct-87 2312 @RELAY.CS.NET:GALLAGHER@cs.umass.edu Extending Defstruct
C01878 00484 ∂06-Oct-87 2333 @RELAY.CS.NET:GALLAGHER@cs.umass.edu Defstruct and CLOS
C01881 00485 ∂07-Oct-87 0011 @RELAY.CS.NET:GALLAGHER@cs.umass.edu Defstruct and CLOS
C01884 00486 ∂08-Oct-87 1028 sandra%orion@cs.utah.edu compile-time actions & top-level forms (long)
C01892 00487 ∂08-Oct-87 1546 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
C01895 00488 ∂08-Oct-87 1639 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
C01898 00489 ∂08-Oct-87 1705 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
C01901 00490 ∂08-Oct-87 1734 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
C01904 00491 ∂08-Oct-87 1744 jbarnett@nrtc.northrop.com I need help
C01906 00492 ∂08-Oct-87 1759 Moon@STONY-BROOK.SCRC.Symbolics.COM compile-time actions & top-level forms (long)
C01909 00493 ∂08-Oct-87 1811 jbarnett@nrtc.northrop.com I need help
C01911 00494 ∂08-Oct-87 1817 jbarnett@nrtc.northrop.com I need help
C01913 00495 ∂08-Oct-87 2337 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
C01916 00496 ∂09-Oct-87 0741 RWK@YUKON.SCRC.Symbolics.COM compile-time actions & top-level forms (long)
C01922 00497 ∂09-Oct-87 0836 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
C01925 00498 ∂09-Oct-87 0951 sandra%orion@cs.utah.edu REQUIRE
C01928 00499 ∂09-Oct-87 1233 cutting.pa@Xerox.COM Re: *REQUIRE-PATHNAME-DEFAULTS*
C01931 00500 ∂09-Oct-87 1338 cutting.pa@Xerox.COM Re: *REQUIRE-PATHNAME-DEFAULTS*
C01934 00501 ∂11-Oct-87 1802 Marion.StudentIM@MIT-Multics.ARPA Mailing List
C01935 00502 ∂11-Oct-87 1858 pyrnj!pyramid!bein@RUTGERS.EDU ...
C01937 00503 ∂11-Oct-87 1921 RAM@c.cs.cmu.edu ... [compile-time lexical environment]
C01939 00504 ∂11-Oct-87 2051 Pavel.pa@Xerox.COM Re: the lexical environment for DEFTYPE, DEFINE-SETF-METHOD and
C01943 00505 ∂12-Oct-87 0908 RAM@C.CS.CMU.EDU the lexical environment for DEFTYPE, DEFINE-SETF-METHOD and
C01947 00506 ∂12-Oct-87 1103 RAM@C.CS.CMU.EDU REQUIRE
C01952 00507 ∂12-Oct-87 1102 pyrnj!pyramid!bein@RUTGERS.EDU defmacro environment again..
C01956 00508 ∂12-Oct-87 1105 RAM@c.cs.cmu.edu defmacro environment again..
C01958 00509 ∂12-Oct-87 1121 pyrnj!pyramid!bein@RUTGERS.EDU defmacro environment again..
C01962 00510 ∂12-Oct-87 1352 RAM@C.CS.CMU.EDU REQUIRE
C01967 00511 ∂12-Oct-87 1916 Pavel.pa@Xerox.COM Re: the lexical environment for DEFTYPE, DEFINE-SETF-METHOD and
C01971 00512 ∂12-Oct-87 2121 @Score.Stanford.EDU:diamant%hpfclp@hplabs.HP.COM Re: REQUIRE
C01975 00513 ∂13-Oct-87 1149 kclmail@rascal.ics.utexas.edu KCL Mailing List
C01978 00514 ∂15-Oct-87 2118 peck@Sun.COM The IDENTITY function and multiple args
C01980 00515 ∂16-Oct-87 0738 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM The IDENTITY function and multiple args
C01983 00516 ∂16-Oct-87 0815 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM The IDENTITY function and multiple args
C01986 00517 ∂16-Oct-87 0825 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM The IDENTITY function and multiple args
C01989 00518 ∂16-Oct-87 0832 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM with-open-stream and with-open-file
C01992 00519 ∂16-Oct-87 1059 Pavel.pa@Xerox.COM Re: with-open-stream and with-open-file
C01995 00520 ∂16-Oct-87 1124 Pavel.pa@Xerox.COM Re: with-open-stream and with-open-file
C01998 00521 ∂16-Oct-87 1311 DCP@YUKON.SCRC.Symbolics.COM Re: with-open-stream and with-open-file
C02003 00522 ∂19-Oct-87 0846 Steve.Handerson@spice.cs.cmu.edu Compiler-let
C02005 00523 ∂19-Oct-87 1051 gls@Think.COM [boyer@rascal.ics.utexas.edu: CLTL]
C02008 00524 ∂24-Oct-87 0130 @RELAY.CS.NET:CORK@cs.umass.edu RE: Extending DEFSTRUCT
C02017 00525 ∂24-Oct-87 1224 TOURETZKY@C.CS.CMU.EDU extending DEFSTRUCT
C02019 00526 ∂24-Oct-87 2036 pyrnj!pyramid!bein@RUTGERS.EDU macrolet/flet/labels
C02021 00527 ∂25-Oct-87 0624 Rick.Busdiecker@H.GP.CS.CMU.EDU extending DEFSTRUCT
C02023 00528 ∂25-Oct-87 0939 norvig%cogsci.Berkeley.EDU@ucbvax.Berkeley.EDU extending DEFSTRUCT
C02025 00529 ∂25-Oct-87 1620 Pavel.pa@Xerox.COM Re: macrolet/flet/labels
C02027 00530 ∂25-Oct-87 1830 RWK@YUKON.SCRC.Symbolics.COM extending DEFSTRUCT
C02033 00531 ∂26-Oct-87 0731 cerys%RTS-12.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: extending DEFSTRUCT
C02035 00532 ∂26-Oct-87 0856 SWM@SAPSUCKER.SCRC.Symbolics.COM Re: macrolet/flet/labels
C02038 00533 ∂26-Oct-87 0934 Moon@ALLEGHENY.SCRC.Symbolics.COM Re: extending DEFSTRUCT
C02041 00534 ∂26-Oct-87 1050 extending DEFSTRUCT
C02044 00535 ∂26-Oct-87 1252 kessler%cons@cs.utah.edu 1988 LISP & FUNCTIONAL PROGRAMMING - CALL FOR PAPERS
C02052 00536 ∂26-Oct-87 1437 @DOUGHNUT.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU suggestion for language extension
C02056 00537 ∂26-Oct-87 1535 @DOUGHNUT.CS.ROCHESTER.EDU,@THINK.COM:barmar@Think.COM suggestion for language extension
C02062 00538 ∂26-Oct-87 2150 COMMON-LISP-mailer extending DEFSTRUCT
C02066 00539 ∂26-Oct-87 2206 Common-Lisp-mailer Re: suggestion for language extension
C02074 00540 ∂27-Oct-87 0933 Common-Lisp-mailer re: defstruct extensions
C02078 00541 ∂27-Oct-87 0944 Common-Lisp-mailer Re: suggestion for language extension
C02086 00542 ∂27-Oct-87 1212 Common-Lisp-mailer Re: macrolet/flet/labels
C02089 00543 ∂27-Oct-87 1744 Common-Lisp-mailer integer-decode-float usage question
C02091 00544 ∂27-Oct-87 1816 Common-Lisp-mailer integer-decode-float usage question
C02094 00545 ∂27-Oct-87 2107 Common-Lisp-mailer Re: integer-decode-float usage question
C02097 00546 ∂28-Oct-87 0215 Common-Lisp-mailer re: defstruct extensions
C02106 00547 ∂28-Oct-87 0915 Common-Lisp-mailer Re: integer-decode-float usage question
C02110 00548 ∂28-Oct-87 1033 Common-Lisp-mailer Re: integer-decode-float usage question
C02114 00549 ∂28-Oct-87 1554 Common-Lisp-mailer Re: suggestion for language extension
C02116 00550 ∂05-Nov-87 0001 Common-Lisp-mailer flet/labels/macrolet
C02126 00551 ∂05-Nov-87 0116 Common-Lisp-mailer flet/labels/macrolet
C02132 00552 ∂05-Nov-87 1950 Common-Lisp-mailer flet/labels/macrolet & environments
C02139 00553 ∂08-Nov-87 1426 Common-Lisp-mailer equality of structures, or *default-structure-type*
C02142 00554 ∂08-Nov-87 1616 Common-Lisp-mailer equality of structures, or *default-structure-type*
C02145 00555 ∂09-Nov-87 0556 Common-Lisp-mailer RE: equality of structures, or *default-structure-type*
C02147 00556 ∂09-Nov-87 1158 Common-Lisp-mailer equality of structures
C02152 00557 ∂09-Nov-87 1159 Common-Lisp-mailer equality of structures
C02157 00558 ∂09-Nov-87 1159 Common-Lisp-mailer equality of structures
C02162 00559 ∂09-Nov-87 1410 Common-Lisp-mailer equality of structures, or *default-structure-type*
C02165 00560 ∂09-Nov-87 1412 Common-Lisp-mailer Access to lexical environment?
C02175 00561 ∂09-Nov-87 1858 Common-Lisp-mailer Question regarding FORMAT with ~:↑ within ~:{
C02179 00562 ∂10-Nov-87 1112 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑ within ~:{
C02183 00563 ∂10-Nov-87 1134 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑ within ~:{
C02185 00564 ∂10-Nov-87 1305 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑
C02187 00565 ∂10-Nov-87 1542 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑
C02189 00566 ∂10-Nov-87 2152 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑ within ~:{
C02193 00567 ∂11-Nov-87 0806 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑ within ~:{
C02195 00568 ∂11-Nov-87 1117 Common-Lisp-mailer flet/labels/macrolet and environments
C02202 00569 ∂11-Nov-87 1631 Common-Lisp-mailer Re: Local redefs of special forms
C02206 00570 ∂11-Nov-87 1800 Common-Lisp-mailer Re: Local redefs of special forms
C02210 00571 ∂11-Nov-87 1912 Common-Lisp-mailer Missing and desired sequence function.
C02214 00572 ∂11-Nov-87 2208 Common-Lisp-mailer Missing and desired sequence function.
C02221 00573 ∂12-Nov-87 2250 Common-Lisp-mailer Missing and desired sequence function.
C02228 00574 ∂12-Nov-87 2255 Common-Lisp-mailer Missing and desired sequence function.
C02230 00575 ∂12-Nov-87 1354 Common-Lisp-mailer Re: Local redefs of special forms
C02234 00576 ∂12-Nov-87 2255 Common-Lisp-mailer Missing and desired sequence function.
C02241 00577 ∂12-Nov-87 2309 Common-Lisp-mailer Missing and desired sequence function.
C02243 00578 ∂13-Nov-87 1122 Common-Lisp-mailer Request for adding to mailing list
C02244 00579 ∂13-Nov-87 1559 Common-Lisp-mailer destructuring in macrolet?
C02247 00580 ∂13-Nov-87 1640 Common-Lisp-mailer destructuring in macrolet?
C02250 00581 ∂13-Nov-87 2016 Common-Lisp-mailer Re: Local redefs of special forms
C02254 00582 ∂13-Nov-87 2018 Common-Lisp-mailer destructuring in macrolet?
C02257 00583 ∂13-Nov-87 2018 Common-Lisp-mailer destructuring in macrolet?
C02260 00584 ∂13-Nov-87 2303 Common-Lisp-mailer destructuring in macrolet?
C02262 00585 ∂14-Nov-87 0139 Common-Lisp-mailer reduce should allow an accessor function to be specified
C02264 00586 ∂14-Nov-87 0826 Common-Lisp-mailer reduce should allow an accessor function to be specified
C02267 00587 ∂14-Nov-87 0922 Common-Lisp-mailer reduce should allow an accessor function to be specified
C02270 00588 ∂14-Nov-87 1405 Common-Lisp-mailer Re: Local redefs of special forms
C02272 00589 ∂14-Nov-87 1417 Common-Lisp-mailer reduce should allow an accessor function to be specified
C02275 00590 ∂14-Nov-87 1453 Common-Lisp-mailer questions about CLOS [original subject: equality of structures]
C02282 00591 ∂15-Nov-87 1814 Common-Lisp-mailer destructuring in macrolet?
C02284 00592 ∂16-Nov-87 1852 Common-Lisp-mailer [Question regarding FORMAT with ~:↑ within ~:{]
C02286 00593 ∂17-Nov-87 1609 Common-Lisp-mailer fill-pointers and adjust-array
C02289 00594 ∂17-Nov-87 1609 Common-Lisp-mailer fill-pointers and adjust-array
C02292 00595 ∂17-Nov-87 2058 Common-Lisp-mailer Implementation Questions
C02296 00596 ∂17-Nov-87 2227 Common-Lisp-mailer Implementation Questions
C02300 00597 ∂17-Nov-87 2356 Common-Lisp-mailer new address
C02303 00598 ∂19-Nov-87 0959 Common-Lisp-mailer assoc question
C02305 00599 ∂19-Nov-87 1116 Common-Lisp-mailer assoc question
C02308 00600 ∂19-Nov-87 1310 Common-Lisp-mailer assoc question
C02310 00601 ∂20-Nov-87 1429 Common-Lisp-mailer Re: assoc question
C02313 00602 ∂24-Nov-87 1340 Common-Lisp-mailer changing the value of *package* within a load?
C02315 00603 ∂29-Nov-87 2253 Common-Lisp-mailer List membership?
C02316 00604 ∂01-Dec-87 1628 Common-Lisp-mailer Forwarding Dr. Ito's message.
C02321 00605 ∂03-Dec-87 1912 Common-Lisp-mailer Open House at IBUKI
C02323 00606 ∂04-Dec-87 1505 Common-Lisp-mailer Symbolics DRIBBLE compatibility?
C02328 00607 ∂07-Dec-87 0945 RPG My E-mail address in Japan
C02330 00608 ∂07-Dec-87 1427 Common-Lisp-mailer Fill pointers and ADJUST-ARRAY
C02333 00609 ∂07-Dec-87 2315 Common-Lisp-mailer structure type specifier
C02335 00610 ∂08-Dec-87 0354 Common-Lisp-mailer structure type specifier
C02338 00611 ∂08-Dec-87 0418 Common-Lisp-mailer Re: Fill pointers and ADJUST-ARRAY
C02342 00612 ∂08-Dec-87 0648 Common-Lisp-mailer Re: structure type specifier
C02346 00613 ∂08-Dec-87 1621 Common-Lisp-mailer Re: structure type specifier
C02348 00614 ∂08-Dec-87 1630 Common-Lisp-mailer Re: structure type specifier
C02351 00615 ∂09-Dec-87 0635 Common-Lisp-mailer Re: structure type specifier
C02354 00616 ∂09-Dec-87 1125 Common-Lisp-mailer Re: structure type specifier
C02357 00617 ∂10-Dec-87 1243 Common-Lisp-mailer please add us to Common Lisp
C02360 00618 ∂10-Dec-87 2214 Common-Lisp-mailer Question about declaration
C02362 00619 ∂11-Dec-87 0227 Common-Lisp-mailer Re: Question about declaration
C02365 00620 ∂11-Dec-87 0800 Common-Lisp-mailer Re: Question about declaration
C02368 00621 ∂11-Dec-87 0850 Common-Lisp-mailer Re: Question about declaration
C02371 00622 ∂11-Dec-87 1211 Common-Lisp-mailer Re: Question about declaration
C02374 00623 ∂12-Dec-87 0032 Common-Lisp-mailer ε1Question about declarationε0
C02377 00624 ∂12-Dec-87 0132 Common-Lisp-mailer Re: structure type specifier
C02380 00625 ∂12-Dec-87 0234 Common-Lisp-mailer string as vector of fixnums ?
C02383 00626 ∂12-Dec-87 1016 Common-Lisp-mailer string as vector of fixnums ?
C02386 00627 ∂12-Dec-87 1215 Common-Lisp-mailer string as vector of fixnums ?
C02389 00628 ∂12-Dec-87 1723 Common-Lisp-mailer sloop
C02392 00629 ∂13-Dec-87 1352 Common-Lisp-mailer ε1Question about declarationε0
C02395 00630 ∂14-Dec-87 0512 Common-Lisp-mailer string as vector of fixnums ?
C02398 00631 ∂14-Dec-87 0527 Common-Lisp-mailer string as vector of fixnums ?
C02403 00632 ∂16-Dec-87 0132 Common-Lisp-mailer Current practice:argument types in function declarations
C02406 00633 ∂16-Dec-87 1045 Common-Lisp-mailer Current practice:argument types in function declarations
C02411 00634 ∂17-Dec-87 0004 Common-Lisp-mailer Re: Current practice:argument types in function declarations
C02415 00635 ∂17-Dec-87 0735 Common-Lisp-mailer ε1Question about declarationε0
C02418 00636 ∂17-Dec-87 1048 Common-Lisp-mailer Types in CL
C02426 00637 ∂17-Dec-87 1220 Common-Lisp-mailer Types in CL
C02430 00638 ∂17-Dec-87 1257 Common-Lisp-mailer Re: Types in CL
C02432 00639 ∂17-Dec-87 1447 Common-Lisp-mailer Types in CL
C02435 00640 ∂17-Dec-87 1452 Common-Lisp-mailer Re: Types in CL
C02439 00641 ∂17-Dec-87 1603 Common-Lisp-mailer Re: Types in CL
C02444 00642 ∂17-Dec-87 1634 Common-Lisp-mailer Types in CL
C02447 00643 ∂18-Dec-87 0629 Common-Lisp-mailer Re: Current practice:argument types in function declarations
C02450 00644 ∂24-Dec-87 1442 Common-Lisp-mailer Re: Types in CL
C02455 00645 ∂26-Dec-87 1933 Common-Lisp-mailer Question about declaration
C02460 00646 ∂27-Dec-87 1421 Common-Lisp-mailer Types in CL
C02463 00647 ∂28-Dec-87 0838 Common-Lisp-mailer Types in CL
C02467 00648 ∂28-Dec-87 0848 Common-Lisp-mailer Types in CL
C02472 00649 ∂29-Dec-87 1126 Common-Lisp-mailer implicit blocks
C02474 00650 ∂29-Dec-87 1206 Common-Lisp-mailer Types in CL
C02478 00651 ∂30-Dec-87 1631 Common-Lisp-mailer function redefinition.
C02482 00652 ∂31-Dec-87 0731 Common-Lisp-mailer Teaching iteration
C02485 00653 ∂31-Dec-87 0831 Common-Lisp-mailer sloop availability
C02487 00654 ∂31-Dec-87 1116 Common-Lisp-mailer implicit blocks
C02491 00655 ∂31-Dec-87 1634 Common-Lisp-mailer Re: implicit blocks
C02500 ENDMK
C⊗;
∂12-Apr-87 0005 kempf%hplabsc@hplabs.HP.COM Re: redefining Common Lisp functions
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 12 Apr 87 00:05:28 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Sat, 11 Apr 87 21:44:51 pst
Received: by hplabsc ; Sat, 11 Apr 87 21:44:52 pst
Date: Sat, 11 Apr 87 21:44:52 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8704120544.AA05619@hplabsc>
To: common-lisp@sail.stanford.edu, masinter.PA@Xerox.COM
Subject: Re: redefining Common Lisp functions
In the process of implementing CommonObjects on CommonLoops (COOL)
I found it necessary to re-implement the following functions:
EQUAL, EQL, EQUALP, TYPEP, and TYPE-OF. I tried a number of ways
to do this, but none seemed safe (= infinite recursions) or
effective (= slowed down the system), except to provide a macro
which a user actually wanting the semantics of the redefined functions
could invoke. This macro defined the functions on uninterned symbols
then shadowing imported the symbols into the package where the user
wanted them. Although this sounds inconvenient, it did allow me to
match CommonObjects semantics (at the user's option, however) which
require these functions to be user specializable, i.e. generic functions.
Jim Kempf kempf@hplabs.hp.com
PS: Portable CommonLoops already allows PRINC and other print functions
to be specialized via. the :PRINT-FUNCTION option. Don't remember if
that made it into the standard, since my CLOS specification is at the
office.
∂12-Apr-87 1750 edsel!bhopal!jonl@navajo.stanford.edu all symbols [and delayed mail]
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 17:50:50 PDT
Received: by navajo.stanford.edu; Sun, 12 Apr 87 17:49:09 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA15379; Sun, 12 Apr 87 15:58:51 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA04732; Sun, 12 Apr 87 16:55:48 PDT
Date: Sun, 12 Apr 87 16:55:48 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704122355.AA04732@bhopal.edsel.com>
To: navajo!Common-Lisp%sail@navajo.stanford.edu
Subject: all symbols [and delayed mail]
[The following message was sent when the "775 LISP symbols" was a hot
topic. Unfortunately, the gateway at navajo.stanford.edu seems to be
a bit recalcitrant -- a problem suffered all too often.]
Return-Path: <navajo!MAILER-DAEMON>
Date: Fri, 10 Apr 87 17:33:35 PST
From: Mail Delivery Subsystem <navajo!MAILER-DAEMON>
Subject: Returned mail: Cannot send message for 3 days
To: bhopal!jonl@edsel.com
----- Transcript of session follows -----
----- Unsent message follows -----
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA01258; Tue, 7 Apr 87 14:10:20 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA25834; Tue, 7 Apr 87 15:06:28 PDT
Date: Tue, 7 Apr 87 15:06:28 PDT
From: edsel!bhopal!jonl (Jon L White)
Message-Id: <8704072206.AA25834@bhopal.edsel.com>
To: navajo!smh%EMS.MEDIA.MIT.EDU
Cc: navajo!DALY%ibm.com,
navajo!common-lisp%sail navajo!hornig%QUABBIN.SCRC.Symbolics.COM
In-Reply-To: navajo!smh@EMS.MEDIA.MIT.EDU's message of Tue, 7 Apr 87 11:31:13 EST
Subject: all symbols
I don't think SIZE belongs in the Lisp package -- it isn't one of the
symbols mentioned in CLtL, p160, as optimization qualities. Perhaps
it is a Franz extension?
As to how it came about that Symbolics has 775 symbols: it occured
nearly a year ago, before the Franz-circulated list I believe, as a
consequence of a cooperative effort between Symbolics and Lucid.
I found the following msg header in my old mail file:
Date: Sun, 18 May 86 18:09 EDT
From: Daniel L. Weinreb <Navajo!DLW@SCRC-QUABBIN.ARPA>
Subject: Orthodoxy in the package world layout.
To: edsel!bhopal!jonl@SU-NAVAJO.ARPA
Cc: dlw@SCRC-QUABBIN.ARPA
In-Reply-To: <8605180533.AA25219@bhopal.edsel.uucp>
Yes, it is certainly our intention that the CL package contain exactly
the documented external symbols, and we've tried hard to get it right.
Checking our set against your set is clearly an excellent cross-check.
In fact, I'm surprised none of us ever thought of it. I'm glad you did,
and thanks for doing the comparison. Now, lemme see what I can figure
out about these discrepencies and how to fix them.
. . .
-- JonL --
∂12-Apr-87 1751 edsel!bhopal!jonl@navajo.stanford.edu redefining Common Lisp functions
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 17:50:56 PDT
Received: by navajo.stanford.edu; Sun, 12 Apr 87 17:49:15 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA15405; Sun, 12 Apr 87 16:09:47 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA04788; Sun, 12 Apr 87 17:06:46 PDT
Date: Sun, 12 Apr 87 17:06:46 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704130006.AA04788@bhopal.edsel.com>
To: navajo!Common-Lisp%sail@navajo.stanford.edu
Subject: redefining Common Lisp functions
Unfortunately, it is hard for an implementation to determine when a user
is truly "redefining" a function, or merely changing it's symbol-function
cell in a way compatible with portable Common Lisp. The most obvious case
in point is the need to install "wrapper-like" function in order to do
traceing. A user ought to be able to implement his own monitoring scheme,
which would involve changing the contents of the symbol-function cell of
an arbitrary Common Lisp function (name), without bumping into some kind
of hard barrier.
-- JonL --
∂12-Apr-87 2225 HEWETT@SUMEX-AIM.STANFORD.EDU Redefining CL fns
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 22:25:45 PDT
Date: Sun, 12 Apr 87 22:24:43 PDT
From: Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>
Subject: Redefining CL fns
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU>
As someone more concerned with using Common LISP and in
the portability of it, I can't believe any responsible
software engineer would even think of redefining a
CL-defined function, macro, or special form.
Therefore, the question of allowing redefinition is purely
a CL environment implementation question, and I would think
that it should be perfectly legal to protect the user from
himself and not allow redefinition.
Mike Hewett
(HEWETT@SUMEX-AIM.STANFORD.EDU)
-------
∂13-Apr-87 1018 sears%wrs.DEC@decwrl.DEC.COM Re: Redefining Common LISP Functions, MACROS and Special Forms
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 13 Apr 87 10:17:56 PDT
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA20408; Mon, 13 Apr 87 09:17:36 PST
Message-Id: <8704131717.AA20408@decwrl.dec.com>
Date: Monday, 13 Apr 1987 09:57:04-PDT
From: sears%wrs.DEC@decwrl.DEC.COM
To: common-lisp@sail.stanford.edu, sears%wrs.DEC@decwrl.DEC.COM
Subject: Re: Redefining Common LISP Functions, MACROS and Special Forms
I think this is a deep issue in the language. This is especially
true for those applications that are evolving systems starting from
COMMON-LISP as a base. I think the questions are:
1. What is the protocol for adding an extension for an
interpreted function.
2. What is the protocol for adding an extension that is compiled.
3. How are "META" functions, such as SETF and DEFSTRUCT,
to be handled.
4. Are some functions to be handled differently than others?
(Forms like OR and MULTIPLE-VALUE-RETURN).
In the case of (1), changing the function cell seems to be adequate.
In the case of (2), the compiler needs to know which definition is
intended. Using a new symbol solves this problem.
The problem in the case of (3) is that a redefined function may imply
(or not) a change to SETF. DEFSETF is the function that does this, but
it in turn is affected by compilation. A related problem is the handling
of DEFSTRUCT accessor, creator and setting functions.
In the case of (4), it may well be the case that the language can
be defined as consisting of layers, but this should be specified explicitly
if this is to be the case.
I think the exact handling of these features needs to be defined in
a way that gives the system builder explicit control.
/wrs
∂13-Apr-87 1216 gls@Think.COM redefining Common Lisp functions
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 13 Apr 87 12:16:35 PDT
Received: from falling-star by Think.COM via CHAOS; Mon, 13 Apr 87 14:19:17 EST
Date: Mon, 13 Apr 87 15:16 EDT
From: Guy Steele <gls@Think.COM>
Subject: redefining Common Lisp functions
To: masinter.PA@xerox.com, common-lisp@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870411-154536-1554@Xerox>
Message-Id: <870413151618.1.GLS@FALLING-STAR.THINK.COM>
Date: 11 Apr 87 14:44:52 PST
From: masinter.PA@xerox.com
Everyone (including Guy Steele!) seems to be challenging me to quote
"chapter and verse" in Guy Steele's book supporting my assertion that it
is an error to redefine any of the predefined Common Lisp functions and
macros. (The appropriate verse which claims that it is an error to
redefine one of the predefined special forms with DEFUN having been
found.)
Larry, the point is that the phrase "is an error" has a precise
technical meaning in CLTL, and is furthermore understood in
conversations on this mailing list to mean "is explicitly stated by CLTL
to `be an error'". If it's just your opinion, then you can legitimately
say "It is stupid to ..." or "It is wedged to ..." or even "It is
erroneous to ..." or (best) "I think it should be an error to ..."; but
if you say simply "It is an error to..." then that is understood to be a
statement of fact about what is in CLTL, and it is reasonable for others
to ask what part of the book backs it up.
We all like you, and we don't mean to challenge you or give you a hard
time. Many of us even agree that it SHOULD be an error. But (unless
I have overlooked the relevant passage) it isn't an error yet.
--Guy
∂13-Apr-87 1516 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Compiling CASE
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 13 Apr 87 15:16:29 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75945; Mon 13-Apr-87 09:53:51 EDT
Date: Mon, 13 Apr 87 09:57 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Compiling CASE
To: Hvatum@MIT-MULTICS.ARPA, Rob MacLachlan <RAM@C.CS.CMU.EDU>, masinter.PA@Xerox.COM,
Jim Kempf <kempf%hplabsc@hplabs.HP.COM>, Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>, common-lisp@SAIL.STANFORD.EDU,
navajo!Common-Lisp%sail@navajo.stanford.edu
In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>,
<RAM.12293665189.BABYL@C.CS.CMU.EDU>,
<RAM.12293670645.BABYL@C.CS.CMU.EDU>,
<870411-154536-1554@Xerox>,
<8704120544.AA05619@hplabsc>,
<8704130006.AA04788@bhopal.edsel.com>,
<12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU>
Message-ID: <870413095719.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Sun, 12 Apr 87 22:24:43 PDT
From: Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>
As someone more concerned with using Common LISP and in
the portability of it, I can't believe any responsible
software engineer would even think of redefining a
CL-defined function, macro, or special form.
I agree, and the implication (or my inference) is that there are
irresponsible engineers, or even the responsible ones make mistakes.
Therefore, the question of allowing redefinition is purely
a CL environment implementation question, and I would think
that it should be perfectly legal to protect the user from
himself and not allow redefinition.
I agree here too. Various implementations do protect the user. The
Symbolics implementation does this by remembering the source file of the
original definition, and if the new source file doesn't match it
queries. This applies to all functions, not just the core language.
Date: Sat, 11 Apr 1987 11:09 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
...
The significance of code walkers has also been exaggerated. For one
thing, modern Lisp compilers tend not to use source code as the
internal representation, and their operation cannot really be modeled
as a source code walk. Given a sufficiently rich representation, many
things can be determined without actually grovelling the code.
Of course internal compiler representations are highly implementation
dependent, but this isn't necessarily a problem. One of the main
things that source code walkers have been used for is writing
"optimizing macros" for non-optimizing compilers. As long as the
compiler adequately optimizes the code, macros can expand in a
simple-minded way without understanding their arguments.
Speak for yourself. They are also used to write embedded languages or
to make semantic extensions to existing languages that require
source-to-source translation to convert the embedded syntax to CLtL.
This is precisely my main use of code walkers. Consider a simple object
oriented system where slots are referenced with AREF. I could (1) go in
and change the compiler, (2) try to use the compiler's internal
representation, or (3) code walk looking for slot names and replace them
with the appropriate AREF forms. (3) is the only method that has any
hope of portability, and the funarg to the code walker is 9 lines of
code.
∂13-Apr-87 1528 @diamond.s4cc.symbolics.com:DCP@QUABBIN.SCRC.Symbolics.COM Compiling CASE
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87 15:28:26 PDT
Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by navajo.stanford.edu with TCP; Mon, 13 Apr 87 15:24:54 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75945; Mon 13-Apr-87 09:53:51 EDT
Date: Mon, 13 Apr 87 09:57 EDT
From: David C. Plummer <DCP@quabbin.scrc.symbolics.com>
Subject: Compiling CASE
To: Hvatum@MIT-MULTICS.ARPA, Rob MacLachlan <RAM@c.cs.cmu.edu>,
masinter.PA@xerox.com, Jim Kempf <kempf%hplabsc@hplabs.hp.com>,
Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
Mike Hewett <HEWETT@sumex-aim.stanford.edu>,
common-lisp@sail.stanford.edu,
navajo!Common-Lisp%sail@navajo.stanford.edu
In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>,
<RAM.12293665189.BABYL@C.CS.CMU.EDU>,
<RAM.12293670645.BABYL@C.CS.CMU.EDU>,
<870411-154536-1554@Xerox>,
<8704120544.AA05619@hplabsc>,
<8704130006.AA04788@bhopal.edsel.com>,
<12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU>
Message-Id: <870413095719.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Sun, 12 Apr 87 22:24:43 PDT
From: Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>
As someone more concerned with using Common LISP and in
the portability of it, I can't believe any responsible
software engineer would even think of redefining a
CL-defined function, macro, or special form.
I agree, and the implication (or my inference) is that there are
irresponsible engineers, or even the responsible ones make mistakes.
Therefore, the question of allowing redefinition is purely
a CL environment implementation question, and I would think
that it should be perfectly legal to protect the user from
himself and not allow redefinition.
I agree here too. Various implementations do protect the user. The
Symbolics implementation does this by remembering the source file of the
original definition, and if the new source file doesn't match it
queries. This applies to all functions, not just the core language.
Date: Sat, 11 Apr 1987 11:09 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
...
The significance of code walkers has also been exaggerated. For one
thing, modern Lisp compilers tend not to use source code as the
internal representation, and their operation cannot really be modeled
as a source code walk. Given a sufficiently rich representation, many
things can be determined without actually grovelling the code.
Of course internal compiler representations are highly implementation
dependent, but this isn't necessarily a problem. One of the main
things that source code walkers have been used for is writing
"optimizing macros" for non-optimizing compilers. As long as the
compiler adequately optimizes the code, macros can expand in a
simple-minded way without understanding their arguments.
Speak for yourself. They are also used to write embedded languages or
to make semantic extensions to existing languages that require
source-to-source translation to convert the embedded syntax to CLtL.
This is precisely my main use of code walkers. Consider a simple object
oriented system where slots are referenced with AREF. I could (1) go in
and change the compiler, (2) try to use the compiler's internal
representation, or (3) code walk looking for slot names and replace them
with the appropriate AREF forms. (3) is the only method that has any
hope of portability, and the funarg to the code walker is 9 lines of
code.
∂13-Apr-87 2016 DON%atc.bendix.com@RELAY.CS.NET Inconsistent keywords for sequence functions
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 Apr 87 20:16:07 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02842; 13 Apr 87 23:08 EDT
Received: from atc.bendix.com by RELAY.CS.NET id aa27455; 13 Apr 87 23:04 AST
Date: Mon, 13 Apr 87 14:07 EDT
From: DON%atc.bendix.com@RELAY.CS.NET
Subject: Inconsistent keywords for sequence functions
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"common-lisp@sail.stanford.edu"
Why do most of the sequence functions have the :key keyword but
reduce doesn't? Why isn't there a reduce-if and a reduce-if-not?
An example which came up recently is
(reduce #'+ box-contents :key #'weight)
which should return the sum of the weights of the objects in the box.
Don Mitchell Don@atc.bendix.com
Bendix Aero. Tech. Ctr. Don%atc.bendix.com@relay.cs.net
9140 Old Annapolis Rd. (301)964-4156
Columbia, MD 21045
∂14-Apr-87 0747 ROSENKING@A.ISI.EDU Redefinition of CL Functions
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 07:47:13 PDT
Date: 14 Apr 1987 10:44:12 EDT
Subject: Redefinition of CL Functions
From: Jeffrey Rosenking <ROSENKING@A.ISI.EDU>
To: common-lisp@SAIL.STANFORD.EDU
cc: rosenking@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: rosenking@A.ISI.EDU
Subject: Redefinition of CL Functions
------------------------------------------------------------------------
13-Apr-87 18:57:41-EDT,3913;000000000001
Return-Path: <@SAIL.STANFORD.EDU,@diamond.s4cc.symbolics.com:DCP@QUABBIN.SCRC.Symbolics.COM>
Received: FROM SAIL.STANFORD.EDU BY USC-ISI.ARPA WITH TCP ; 13 Apr 87 18:53:02 EDT
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87 15:28:26 PDT
Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by navajo.stanford.edu with TCP; Mon, 13 Apr 87 15:24:54 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75945; Mon 13-Apr-87 09:53:51 EDT
Date: Mon, 13 Apr 87 09:57 EDT
From: David C. Plummer <DCP@quabbin.scrc.symbolics.com>
Subject: Compiling CASE
To: Hvatum@MIT-MULTICS.ARPA, Rob MacLachlan <RAM@c.cs.cmu.edu>,
masinter.PA@xerox.com, Jim Kempf <kempf%hplabsc@hplabs.hp.com>,
Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
Mike Hewett <HEWETT@sumex-aim.stanford.edu>,
common-lisp@sail.stanford.edu,
navajo!Common-Lisp%sail@navajo.stanford.edu
In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>,
<RAM.12293665189.BABYL@C.CS.CMU.EDU>,
<RAM.12293670645.BABYL@C.CS.CMU.EDU>,
<870411-154536-1554@Xerox>,
<8704120544.AA05619@hplabsc>,
<8704130006.AA04788@bhopal.edsel.com>,
<12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU>
Message-Id: <870413095719.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Sun, 12 Apr 87 22:24:43 PDT
From: Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>
As someone more concerned with using Common LISP and in
the portability of it, I can't believe any responsible
software engineer would even think of redefining a
CL-defined function, macro, or special form.
I agree, and the implication (or my inference) is that there are
irresponsible engineers, or even the responsible ones make mistakes.
Therefore, the question of allowing redefinition is purely
a CL environment implementation question, and I would think
that it should be perfectly legal to protect the user from
himself and not allow redefinition.
I agree here too. Various implementations do protect the user. The
Symbolics implementation does this by remembering the source file of the
original definition, and if the new source file doesn't match it
queries. This applies to all functions, not just the core language.
I agree here too, too ! In response to the discussions above (Hewett, Masinter, Plummer, and Steele),
and my feelings on the subject, I THINK that the CL standard should support
a mechanism to, at least, warn the user if he attempts to redefine a CL-defined
function, macro, or special form [ or perhpas initiate an error, though I
believe that this will not coincide with the tradional flexibility which LISP
has always had ]. The Symbolics implementation [of a redefinition WARNING
mechanism] would be a good model for the analagous CL mechanism, and it has
the advantage of working for the definition of all functions, not just those
which are strictly CL-defined. I BELIEVE that this mechanism is an essential
part of a language, especially one which was mainly designed to support
portability and commonality among various LISP implementations.
-: Jeff
-------
-------
∂14-Apr-87 0851 kempf%hplabsc@hplabs.HP.COM Re: Redefinition of CL Functions
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87 08:51:30 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Tue, 14 Apr 87 07:43:17 pst
Received: by hplabsc ; Tue, 14 Apr 87 07:44:30 pst
Date: Tue, 14 Apr 87 07:44:30 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8704141544.AA07256@hplabsc>
To: ROSENKING@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU
Subject: Re: Redefinition of CL Functions
Cc: rosenking@A.ISI.EDU
While I understand the concern about redefinition causing code
to become nonportable, I think a case can be made for redefinition
in experimental systems. Particularly when one is developing
embedded languages, the semantics of certain Common Lisp functions
may need to be changed. An example here is CommonObjects, which
extends the semantics of certain Common Lisp functions to include
user defined types. Naturally, this is not something one does
casually, in the course of developing a Common Lisp application,
but rather should be labelled by the developer as being an extension
to be used with care. A warning message upon redefinition would
be sufficient, signalling an error would remove some of the flexibility
which makes Common Lisp such an ideal environment for developing
embedded languages.
Jim Kempf kempf@hplabs.hp.com
∂14-Apr-87 0924 RAM@C.CS.CMU.EDU Redefinition of CL Functions
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 09:24:31 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 14 Apr 87 12:13:37-EDT
Date: Tue, 14 Apr 1987 12:13 EDT
Message-ID: <RAM.12294468669.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Jim Kempf <kempf%hplabsc@HPLABS.HP.COM>
Cc: common-lisp@SAIL.STANFORD.EDU, ROSENKING@A.ISI.EDU
Subject: Redefinition of CL Functions
In-reply-to: Msg of 14 Apr 1987 11:44-EDT from Jim Kempf <kempf%hplabsc at hplabs.HP.COM>
One point that should be introduced into this discussion is the
distinction between "legal" and "reasonable". It is not feasible for
Common Lisp to mandate reasonableness; users will have to decide for
themselves whether a given implementation is reasonable. With any
standard it is possible to create a system that complies with the
letter of the standard, but is still totally unusable.
In the case of redefinitions of standard functions and macros I would
say that reasonable implementations should both:
-- Warn when the user redefines a standard function or macro and
-- Do its best to make the user redefinition work.
I don't think either property can be brought within the formal
language definition, so an implementation that flames out and dies
when you redefine a standard function would be legal.
Rob
∂14-Apr-87 0949 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Redefinition of CL Functions
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 14 Apr 87 09:48:58 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 71623; Tue 14-Apr-87 12:38:03 EDT
Date: Tue, 14 Apr 87 12:34 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Redefinition of CL Functions
To: kempf%hplabsc@hplabs.HP.COM, ROSENKING@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8704141544.AA07256@hplabsc>
Message-ID: <870414123431.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Tue, 14 Apr 87 07:44:30 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
While I understand the concern about redefinition causing code
to become nonportable, I think a case can be made for redefinition
in experimental systems.
However, as Rob explained in a recent message, the only reason for the
Common Lisp specification to provide for anything is in order to make
sure that doing the thing is guaranteed to be portable across all
implementations of Common Lisp. If it's not going to be portable, then
there's no point in putting it in the Common Lisp specification. If it
is supposed to be portable, there are all the serious problems that have
been pointed out in recent mail. There's nothing wrong with a particular
implementation having some kind of feature that allows redefinition of
built-in functions/macros/etc.
∂14-Apr-87 1010 sears%wrs.DEC@decwrl.DEC.COM Re: Inconsistencies in Sequence Function Arguments
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87 10:10:27 PDT
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA19382; Tue, 14 Apr 87 09:10:14 PST
Message-Id: <8704141710.AA19382@decwrl.dec.com>
Date: Tuesday, 14 Apr 1987 09:48:40-PDT
From: sears%wrs.DEC@decwrl.DEC.COM
To: common-lisp@SAIL.STANFORD.EDU, sears%wrs.DEC@decwrl.DEC.COM
Subject: Re: Inconsistencies in Sequence Function Arguments
I agree that REDUCE should take a :KEY keyword. There seems to be
little difficulty in implementing it, I have found it frequently
useful, and it provides consistency with the other sequence functions. The
change is upward compatible with the existing language.
/wrs
∂14-Apr-87 1013 Moon@STONY-BROOK.SCRC.Symbolics.COM Inconsistent keywords for sequence functions
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87 10:12:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 115506; Tue 14-Apr-87 13:10:15 EDT
Date: Tue, 14 Apr 87 13:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Inconsistent keywords for sequence functions
To: DON%atc.bendix.com@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 13 Apr 87 14:07 EDT from DON%atc.bendix.com@RELAY.CS.NET
Message-ID: <870414130937.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 13 Apr 87 14:07 EDT
From: DON%atc.bendix.com@RELAY.CS.NET
Why do most of the sequence functions have the :key keyword but
reduce doesn't? Why isn't there a reduce-if and a reduce-if-not?
An example which came up recently is
(reduce #'+ box-contents :key #'weight)
which should return the sum of the weights of the objects in the box.
:key, -if, and -if-not only apply to functions that have :test arguments.
I can't imagine what reduce-if and reduce-if-not would do. I can see
what you want reduce :key to do, but I'm not sure :key is the right name
for that.
In retrospect, it might have been better language design to have fewer
options combined with stronger encouragement of implementations to
compile efficient code for nested function invocations, compiling out
temporary storage. Thus your example would be written:
(reduce #'+ (mapcar #'weight box-contents))
I realize quite well that there are a number of practical and philosophical
problems connected with actually doing this; please let's not start a long
discussion of them.
∂14-Apr-87 1131 Moon@STONY-BROOK.SCRC.Symbolics.COM redefining Common Lisp functions
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87 11:20:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 115605; Tue 14-Apr-87 14:19:35 EDT
Date: Tue, 14 Apr 87 14:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: redefining Common Lisp functions
To: masinter.PA@Xerox.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870411-154536-1554@Xerox>
Message-ID: <870414141907.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 11 Apr 87 14:44:52 PST
From: masinter.PA@Xerox.COM
Rather than attempting to divine meaning in CLtL, lets focus on some
related but different questions:
1. (Current practice) In your favorite Common Lisp implementation, which
of the predefined Common Lisp functions, macros, and special forms can
be safely redefined without causing unpredictable behavior somewhere
else in the system?
I don't know what "safely" means; I made an assumption about what you meant
such that the answer is "none of them, not only in my favorite implementation,
but in all the others too."
2. (Future standards) Which of the predefined Common Lisp functions,
macros, and special forms do you think *should* be redefinable.
I don't believe that Common Lisp should define the meaning of redefining
any of the predefined functions. Thus I believe that it should "be an error"
to redefine any predefined function. JonL's point about the difference between
truly redefining something and merely encapsulating it (e.g. for TRACE) is
relevant here. But note that I do not believe that Common Lisp should require
compiled code that appears to call a predefined function, macro, or special
form to be necessarily affected by any encapsulation of that functionoid.
3. (More constrained redefining) Presuming the CLOS, which of the
predefined Common Lisp functions should be specializable for
user-defined classes? How should such specialization affect the rest of
the behavior of Common Lisp?
The working group for defining the proposed object-oriented programming
standard ("CLOS") has thought about this just enough to realize that it
is complex and difficult. The group, or someone, will have to do more
work in this area, but it's not going to be easy.
∂14-Apr-87 1148 VERACSD@A.ISI.EDU Format
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 11:48:20 PDT
Date: 14 Apr 1987 14:47-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Format
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]14-Apr-87 14:47:31.VERACSD>
Is there a FORMAT directive that prints real numbers as integers
(truncated or rounded), without a decimal point?
∂14-Apr-87 1204 FAHLMAN@C.CS.CMU.EDU Format
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 12:04:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 14 Apr 87 15:04:20-EDT
Date: Tue, 14 Apr 1987 15:04 EDT
Message-ID: <FAHLMAN.12294499763.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: VERACSD@A.ISI.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Format
In-reply-to: Msg of 14 Apr 1987 14:47-EDT from VERACSD at A.ISI.EDU
Is there a FORMAT directive that prints real numbers as integers
(truncated or rounded), without a decimal point?
I'm not sure, but I don't think so. Why not call Truncate or Round on
the number and then format it with ~D ?
-- Scott
∂14-Apr-87 1706 sears%wrs.DEC@decwrl.DEC.COM Re: Redefinition of CL Functions
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87 17:05:58 PDT
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA29331; Tue, 14 Apr 87 16:06:46 PST
Message-Id: <8704150006.AA29331@decwrl.dec.com>
Date: Tuesday, 14 Apr 1987 10:10:11-PDT
From: sears%wrs.DEC@decwrl.DEC.COM
To: common-lisp@SAIL.STANFORD.EDU, sears%wrs.DEC@decwrl.DEC.COM
Subject: Re: Redefinition of CL Functions
Are there cases where shadowing COMMON LISP symbols, then giving the
shadowing symbols new definitions does not provide sufficient capability
to layer extensions on a COMMON LISP implementation?
I built a layered language for instrumentation, and used shadowed symbols
to provide the new definitions. This works fine in VAXLISP.
It was necessary to provide type definitions for symbols used as both
a function and a type (LIST, STRING, etc), and to provide DEFSETF
expanders for the new names. Are there other known problems?
This approach is well defined because you know which definition you are
using (It depends on the package in effect when the file is read or compiled),
and it is straightforward to reference the standard definition if it is
needed. It also works with our compiler, which does not optimize
any of the new definitions, since it doesn't recognize any of the
new functions.
Incidentally, VAX LISP gives a warning message when you try to redefine
a built-in COMMON-LISP function.
/wrs
∂14-Apr-87 1829 jcm@ORNL-MSR.ARPA Flavors and DEC's VMS Common Lisp?
Received: from ORNL-MSR.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87 18:29:04 PDT
Received: by ORNL-MSR.ARPA (5.51/4.9)
id AA21592; Tue, 14 Apr 87 21:29:58 EST
Date: Tue, 14 Apr 87 21:29:58 EST
From: jcm@ORNL-MSR.ARPA (James A. Mullens)
Message-Id: <8704150229.AA21592@ORNL-MSR.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Flavors and DEC's VMS Common Lisp?
[He was new to the group, he couldn't locate the mail archives, so he had
to ask a newcomer's question...
]
Has anyone done a public-domain implementation of Symbolics-style flavors
for DEC VMS CL? We have found a flavors package for Golden Common Lisp
which we are considering porting... any comments?
jim mullens / jcm@ornl-msr.arpa / oak ridge national lab
∂14-Apr-87 2056 kempf%hplabsc@hplabs.HP.COM Re: Redefinition of Common Lisp Functions
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87 20:56:40 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Tue, 14 Apr 87 16:06:24 pst
Received: by hplabsc ; Tue, 14 Apr 87 16:06:53 pst
Date: Tue, 14 Apr 87 16:06:53 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8704150006.AA14181@hplabsc>
To: common-lisp@sail.stanford.edu
Subject: Re: Redefinition of Common Lisp Functions
I guess I need to clarify my comments. I see two competing needs here:
1) On the one hand, system vendors and applications distributors
require the option of not allowing users to redefine Common
Lisp functions. Allowing users to do so makes supplying safe,
good quality software difficult because regression testing becomes next to
impossible.
2) On the other, researchers and people prototyping advanced
applications might want to modify the semantics of certain
Common Lisp functions for experimental purposes.
It seems to me that protection of functions could be included
in postdevelopment packaging, perhaps by setting a switch or
on a package by package basis. The method I used to modify EQ, etc. in
CommonObjects may, in fact, be the desired one: shadow those
Common Lisp functions in the packages where the modified
functions are desired with noninterned symbols having the
same print names as the functions. Attempts to directly redefine
the functions may cause an error to be signalled.
This technique would require no changes in the standard, or
the standard could be toughened up to require that an error
be signalled, as long as it is not toughened to the point
where shadowing Common Lisp functions is an error.
With regard to Moon's comments about the CLOS:
> 3. (More constrained redefining) Presuming the CLOS, which of the
> predefined Common Lisp functions should be specializable for
> user-defined classes? How should such specialization affect the rest of
> the behavior of Common Lisp?
>
>The working group for defining the proposed object-oriented programming
>standard ("CLOS") has thought about this just enough to realize that it
>is complex and difficult. The group, or someone, will have to do more
>work in this area, but it's not going to be easy.
I agree. There are a core set of functions which object-oriented
application developers usually say they want to be specializable,
but, considering the wide variety of Common Lisp implementations
out there, it may be difficult to provide them without stepping
on someone's toes.
Jim Kempf kempf@hplabs.hp.com
∂14-Apr-87 2256 MURRAY%cs.umass.edu@RELAY.CS.NET EVAL-WHEN symbols
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Apr 87 22:56:10 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ah21989; 15 Apr 87 1:31 EDT
Received: from cs.umass.edu by RELAY.CS.NET id bd04862; 15 Apr 87 1:28 AST
Date: Tue, 14 Apr 87 15:45 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SAIL.STANFORD.EDU
Subject: EVAL-WHEN symbols
X-VMS-To: CSNET%"common-lisp@sail.stanford.edu"
While on the topic of symbols and such, I have a question
about EVAL-WHEN. Does it only allow LISP:EVAL, LISP:COMPILE
and LISP:LOAD, or does it only check the print-name?
I think it should check print-names, so you can
shadow these symbols. Otherwise, you would be forced
to add the package prefix in all the EVAL-WHEN forms.
Kelly
∂15-Apr-87 0236 pyramid!pyramid.UUCP!bein@hplabs.HP.COM macroexpand inside of macrolet...
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87 02:36:13 PDT
Received: by hplabs.HP.COM ; Wed, 15 Apr 87 01:36:06 pst
Received: from manpyrnova
by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86)
id AA26478; Wed, 15 Apr 87 02:09:31 PDT
Received: by pyrnova.pyramid.COM (5.52/UUCP-Project/rel-1.0/09-11-86)
id AA11138; Wed, 15 Apr 87 02:09:17 PDT
Date: 15 Apr 1987 01:59 PDT
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: macroexpand inside of macrolet...
To: hplabs!common-lisp@sail.stanford.edu@hplabs.HP.COM
Message-Id: <545474120/bein@pyrnova>
I was playing around inside some macrolet code and came across
what seems to a be a problem (if this issue was discussed ages ago
on this mailing list, please pardon me for raising it again).
(MACROLET ((CONS (A B) `(LIST ',A ',B)))
(MACROEXPAND '(CONS 1 2)))
returns (CONS 1 2) and NIL, while
(MACROLET ((CONS (A B) `(LIST ',A ',B)))
#'CONS)
blows up since FUNCTION sees the local macro definition.
Getting a handle on the local macro environment seems to be
next to impossible. Is there some good reason for this?
Should function be paying attention to the MACROLET
environment in the same way as it does for FLET/LABELS or is
this a bug in my implementation?
Does anyone out there agree with the idea that
macroexpanding something inside the body of a macrolet
is a useful thing to do?
From a debugging standpoint, the current situation
makes it difficult to see what is going on since
there is no "defined" way to see what is currently
defined and of course using something like #'FOO
is ok except if FOO is a macrolet creation.
I suggest the following:
(1) Either MACRO-FUNCTION should be changed to notice
the local macro or some new function be defined
for getting at the local macro environment.
(2) Either MACROEXPAND should by default use the
current environment (implementation specific of
course!) or a new function should be defined
for doing the same thing or perhaps the time
has arrived for a way to access the environment
in a general way.
Comments?
--David
p.s. This whole bag of %&$# would go away if macrolet were
to vaporize itself from the language.
∂15-Apr-87 0818 FAHLMAN@C.CS.CMU.EDU Redefinition of Common Lisp Functions
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 08:18:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Apr 87 11:08:02-EDT
Date: Wed, 15 Apr 1987 11:07 EDT
Message-ID: <FAHLMAN.12294718886.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jim Kempf <kempf%hplabsc@HPLABS.HP.COM>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Redefinition of Common Lisp Functions
In-reply-to: Msg of 14 Apr 1987 20:06-EDT from Jim Kempf <kempf%hplabsc at hplabs.HP.COM>
Attempts to directly redefine
the functions may cause an error to be signalled.
This technique would require no changes in the standard, or
the standard could be toughened up to require that an error
be signalled, as long as it is not toughened to the point
where shadowing Common Lisp functions is an error.
Unless I missed something, nobody is proposing that SHADOWING a built-in
function using the package system should signal an error or should "be
an error". That's what the package system is for.
Clobbering the definitions of built-in symbols in the Lisp package is
another matter. I think there's pretty general agreement that this
should be an "is an error situation", and that it would be tasteful to
at least issue a warning in such cases, perhaps under control of a magic
implementation-dependent switch.
-- Scott
∂15-Apr-87 0818 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM macroexpand inside of macrolet...
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 15 Apr 87 08:18:22 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76897; Wed 15-Apr-87 11:14:49 EDT
Date: Wed, 15 Apr 87 11:18 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: macroexpand inside of macrolet...
To: David Bein <pyramid!bein@hplabs.HP.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <545474120/bein@pyrnova>
Message-ID: <870415111824.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: 15 Apr 1987 01:59 PDT
From: David Bein <pyramid!bein@hplabs.HP.COM>
I was playing around inside some macrolet code and came across
what seems to a be a problem (if this issue was discussed ages ago
on this mailing list, please pardon me for raising it again).
(MACROLET ((CONS (A B) `(LIST ',A ',B)))
(MACROEXPAND '(CONS 1 2)))
returns (CONS 1 2) and NIL, while
(MACROLET ((CONS (A B) `(LIST ',A ',B)))
#'CONS)
blows up since FUNCTION sees the local macro definition.
You are confusing compile-time environments with runtime environments.
MACROLET works on code. MACROEXPAND works on structure. Unless you can
somehow grab ahold, at runtime, of the environment MACROLET has created
and pass that environment to MACROEXPAND you won't get what you are
looking for. How about
(MACROEXPAND-all '(MACROLET ((CONS (A B) `(LIST ',A ',B)))
(CONS 1 2)))
=> (MACROLET ((CONS (A B) `(LIST ',A ',B)))
(LIST '1 '2))
where MACROEXPAND-all (not in CL) does a macroexpanding code walk.
∂15-Apr-87 0903 FAHLMAN@C.CS.CMU.EDU EVAL-WHEN symbols
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 09:03:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 15 Apr 87 11:55:44-EDT
Date: Wed, 15 Apr 1987 11:55 EDT
Message-ID: <FAHLMAN.12294727565.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MURRAY%cs.umass.edu@RELAY.CS.NET
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: EVAL-WHEN symbols
In-reply-to: Msg of 14 Apr 1987 15:45-EDT from MURRAY%cs.umass.edu at RELAY.CS.NET
While on the topic of symbols and such, I have a question
about EVAL-WHEN. Does it only allow LISP:EVAL, LISP:COMPILE
and LISP:LOAD, or does it only check the print-name?
I think it should check print-names, so you can
shadow these symbols. Otherwise, you would be forced
to add the package prefix in all the EVAL-WHEN forms.
Eval-when is currently defined to look for EVAL, COMPILE, and LOAD as
symbols in the Lisp package. Maybe they should have been keywords, but
it's too late now. There's a reasonably good chance that EVAL-WHEN will
be replaced in some future badly-needed cleanup of the compiler semantics.
-- Scott
∂15-Apr-87 0955 weeks%hplbgw%hplb29a@hplabs.HP.COM Re: EVAL-WHEN symbols
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87 09:55:14 PDT
Received: from hplb29a by hplabs.HP.COM with TCP ; Wed, 15 Apr 87 08:51:53 pst
Received: from hplbgw (hplbgw) by hplb29a ; Wed, 15 Apr 87 08:52:10 pst
Received: by hplbgw ; Wed, 15 Apr 87 08:54:32 pst
Date: Wed, 15 Apr 87 08:54:32 pst
From: Gregory Weeks <weeks%hplbgw%hplb29a@hplabs.HP.COM>
Message-Id: <8704151654.AA00676@hplbgw>
To: MURRAY%RELAY.CS.NET%%SAIL.STANFORD.EDU%hplabs@cs.umass.edu,
common-lisp@SAIL.STANFORD.EDU
Subject: Re: EVAL-WHEN symbols
While on the topic of symbols and such, I have a question
about EVAL-WHEN. Does it only allow LISP:EVAL, LISP:COMPILE
and LISP:LOAD, or does it only check the print-name?
I think it should check print-names, so you can
shadow these symbols. Otherwise, you would be forced
to add the package prefix in all the EVAL-WHEN forms.
Now that you mention it: EVAL, COMPILE, and LOAD should have been
keywords.
∂15-Apr-87 0957 Masinter.pa@Xerox.COM Re: macroexpand inside of macrolet...
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87 09:57:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 APR 87 09:55:07 PDT
Date: 15 Apr 87 09:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: macroexpand inside of macrolet...
In-reply-to: David Bein <pyramid!bein@hplabs.HP.COM>'s message of 15 Apr
87 01:59 PDT
To: common-lisp@sail.stanford.edu
Message-ID: <870415-095507-4213@Xerox>
The issue of a lexical environment argument to macroexpand and
macroexpand-1 was discussed at length on this list as well as on the
cleanup committee list.
The problem doesn't go away with the removal of macrolet, because FLET
and LABELS can shadow macros, too.
∂15-Apr-87 1034 Masinter.pa@Xerox.COM Re: EVAL-WHEN symbols
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87 10:34:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 APR 87 10:34:02 PDT
Date: 15 Apr 87 10:35 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: EVAL-WHEN symbols
In-reply-to: MURRAY%cs.umass.edu@RELAY.CS.NET's message of Tue, 14 Apr
87 15:45 EDT
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
Message-ID: <870415-103402-4296@Xerox>
If you want to shadow any of EVAL, LOAD or COMPILE and leave EVAL-WHEN,
you can do so by shadowing EVAL-WHEN with a new EVAL-WHEN which checks
for your new symbols and transforms them to the old.
Ugly, but simple.
∂15-Apr-87 1306 Mailer@XX.LCS.MIT.EDU Compiling CASE
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 13:06:47 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Apr 87 16:04-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 38194; 15 Apr 87 14:59:02-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 32893; 14 Apr 87 16:34:08-EDT
Date: Tue, 14 Apr 87 16:32 EDT
From: Don Morrison <dfm@JASPER.PALLADIAN.COM>
Subject: Compiling CASE
To: Hvatum@MIT-MULTICS.ARPA, barmar@Think.COM
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>
Message-ID: <870414163245.2.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>
Date: Sat, 11 Apr 87 06:07 EDT
From: Hvatum@MIT-MULTICS.ARPA
To Don Morrison: What is the meaning of declaring a MACRO NOTINLINE?
CLtL doesn't imply that this is even possible.
(Which is not to say that CLtL implies that it ISN'T possible - I'm
being very careful with my wording here.)
You and barmar are right; my brain was turned off. Notinline has nothing to do with
it. Sorry about that.
Date: Fri, 10 Apr 87 12:58 EDT
From: Barry Margolin <barmar@Think.COM>
Date: Wed, 8 Apr 87 10:37 EDT
From: Don Morrison <dfm@jasper.palladian.com>
I wonder, however, if all implementations do the right thing if you declare a macro
which is treated specially as notinline?
I don't think it should be necessary to declare/proclaim a macro
notinline. For the macro to work at all, the defmacro must be seen by
the compiler before it tries to compile the use of the macro. I would
hope that the macro would be smart enough to notice that the user has
overridden the default definition.
∂15-Apr-87 2258 sandra%orion@cs.utah.edu bignums are bogus
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 22:58:29 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA02358; Thu, 16 Apr 87 00:01:08 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA15364; Thu, 16 Apr 87 00:01:04 MDT
Date: Thu, 16 Apr 87 00:01:04 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8704160601.AA15364@utah-orion.ARPA>
Subject: bignums are bogus
To: common-lisp@sail.stanford.edu
(Time to get out the asbestos suit -- I'm sure this is going to generate
a lot of flamage....)
Quoting from CLtL (p 13): "Common Lisp in principle imposes no limit on
the magnitude of an integer; storage is automatically allocated as
necessary to represent large integers."
This is the only statement I can find on the subject of how large integers
can be in CL. I think we can probably all agree that every implementation
does impose *some* limit on the size of integers; I don't know of any machine
that has an infinitely large amount of memory, or even an infinitely large
address space. I expect some implementations of bignums have other
constraints as well: assuming the number of bigits is a fixnum, storing
the bigits in an array (limiting the number of bigits to the maximum array
size), or similar representation-related problems.
Three questions:
(1) What is supposed to happen if the user attempts to create an integer
larger than the implementation can support? An easy way to do this would
be to make several layers of calls to "ash":
(let ((huge most-positive-fixnum))
(dotimes (i most-positive-fixnum)
(setq huge (+ huge (ash huge huge))))
huge)
(2) If "it is an error" to create a bignum larger than the implementation
can handle, how can user programs detect and avoid this situation? If the
constraint is in the representation, having a constant to indicate the
maximum number of bits is a possibility, but if the problem is running out
of memory, it wouldn't be of much use.
(3) Given that every implementation has some practical limit on the size of
integers, but CLtL leaves that limit unspecified, is there any reason why
an implementation couldn't choose to make that limit fairly small, like 32
or 64 bits or whatever the largest machine integer size is? (I realize
that doing so might break the Universal Time functions, but I've already
noted that it's fairly easy to break other built-in functions as well,
regardless of how big integers can be.) For that matter, what if the
maximum size of an integer just happened to be the maximum size of a fixnum?
-Sandra
-------
∂16-Apr-87 0834 FAHLMAN@C.CS.CMU.EDU bignums are bogus
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 08:33:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 16 Apr 87 11:04:34-EDT
Date: Thu, 16 Apr 1987 09:13 EDT
Message-ID: <FAHLMAN.12294960256.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: bignums are bogus
In-reply-to: Msg of 16 Apr 1987 02:01-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
The intent of that passage is that the size of bignums should be *much*
larger than the size of fixnums. It is true that the language does not
require that bignums be able to exhaust *all* of the machine's available
address space (or swap space), and that other implementation limits
(such as the maximum array index being a fixnum) may intrude in some
cases. But I think that any implementation that doesn't normally allow
bignums of at least a few K bytes is cheating on the spirit, if not the
letter, of the specification.
As for how these things die when you finally reach the overflow point, I
think that this was viewed as a rare enough thing that it wasn't worth
trying to standardize it as a separate error type. Presumably you get
the same effect that you would get if you exhausted the available space
in some other way, or if you asked for an array bigger than the space
remaining. It is tasteful for this to be a clean, recoverable error,
but it is not required to be -- there has to be some freedom here, since
operating systems vary in the control they give you over memory
allocation and the amount of information they will give you about
available space.
-- Scott
∂16-Apr-87 0834 RAM@C.CS.CMU.EDU bignums are bogus
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 08:33:23 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 16 Apr 87 11:05:25-EDT
Date: Thu, 16 Apr 1987 10:27 EDT
Message-ID: <RAM.12294973589.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: bignums are bogus
In-reply-to: Msg of 16 Apr 1987 02:01-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
Date: Thursday, 16 April 1987 02:01-EDT
From: sandra%orion at cs.utah.edu (Sandra J Loosemore)
To: common-lisp at sail.stanford.edu
Re: bignums are bogus
Three questions:
(1) What is supposed to happen if the user attempts to create an integer
larger than the implementation can support?
A reasonable implementation would signal an error of some sort,
although if paging space is physically exhausted it may be difficult
for Lisp to recover gracefully. Many OS'es don't provide any way to
user programs to tell how how much paging space is left, and tend to
wedge in various ways when it exhausted.
(2) If "it is an error" to create a bignum larger than the implementation
can handle, how can user programs detect and avoid this situation?
The problem with running out of storage has no special relation to
bignums of course. Some programs may require data structures larger
than some implementations can support on a given hardware
configuration. This is a potential portability problem, but I see
nothing that can be done about it.
(3) Given that every implementation has some practical limit on
the size of integers, but CLtL leaves that limit unspecified, is
there any reason why an implementation couldn't choose to make
that limit fairly small, like 32 or 64 bits or whatever the
largest machine integer size is? For that matter, what if the
maximum size of an integer just happened to be the maximum size of
a fixnum?
Your implementation might reasonably be considered to be unreasonable,
and not in the spirit of the specification. As I said earlier, it is
quite possible to build an implementation that compiles with the
letter of a specification and is still totally unusable.
I'm not a big bignum user, but I think it might be marginally
reasonable to support fixed-size 64 bit bignums. I suspect that 64
bit bignums would take care of a large percentage of uses. This would
also keep get-universal-time happy for a while to come.
Perhaps Common Lisp should specify a minimum maximum size for bignums
and require that an error be signalled if this is ever exceeded. I
would guess that a limit of a few thousand bits would meet every use
except the most common, namely impressing non-lispers by typing
(FACT 1000) and getting screens full of digits.
Rob
∂16-Apr-87 0837 vrotney@vaxa.isi.edu CLARIFICATION: [italics]package arguments.
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 08:37:52 PDT
Received: from hpai00 (hpai00.isi.edu) by vaxa.isi.edu (4.12/4.7)
id AA28527; Thu, 16 Apr 87 00:16:39 pst
Received: by hpai00 ; Thu, 16 Apr 87 01:15:33 pdt
From: vrotney@vaxa.isi.edu
Message-Id: <8704160815.AA02532@hpai00>
Date: Thu, 16 Apr 87 00:15:23 PDT
Subject: CLARIFICATION: [italics]package arguments.
To: common-lisp@SAIL.STANFORD.EDU
X-Mailer: NMail [$Revision: 2.6 $]
Are the package functions that take a package argument in CLTL with
the name [italics]package allowed to have a string or symbol as that
argument? If so, HP take note, we had to make a lot of changes in our
Symbolics generated code to make it port to CL on the HPAIWS. If not,
then why not?
Bill Vrotney USC/ISI
-------
∂16-Apr-87 0859 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM bignums are bogus
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Apr 87 08:59:26 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77243; Thu 16-Apr-87 09:32:15 EDT
Date: Thu, 16 Apr 87 09:35 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: bignums are bogus
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>, common-lisp@sail.stanford.edu
In-Reply-To: <8704160601.AA15364@utah-orion.ARPA>
Message-ID: <870416093545.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Character-Type-Mappings: (1 0 (NIL 0) (:FIX :BOLD :NORMAL) "CPTFONTCB")
Fonts: CPTFONT, CPTFONTCB
I believe the spirit of CL is to encourage implementations to make the
maximum size of bignums "reasonably large". I also believe the spirit
of CL is to have the lower limit be rather large, say at least 5000
bits. The smaller the size of the largest bignum, the more applications
you lock out, such as symbolic algebras.
If you make the maximum size of an integer be the maximum size of a
fixnum, does that imply (+ most-positive-fixnum 1) generates an error?
I agree that a CLtL-defined implementation-dependent constant describing
the maximum number of bits of a bignum is consistent with CLtL; I'm not
sure how applications would make use of it, other than
(when (< maximum-number-of-bignum-bits 9342)
(error "This application won't work on this machine; bignums are too small."))
BTW, the Symbolics 3600 implementation limits bignums to 2↑28 bits.
Applications that create such things are going to page like mad. The
error that is generated when exceeding is along the lines
(ash 1 most-positive-fixnum)
ε1Error: ASH shifting much too far to the left
∂16-Apr-87 0930 DLA@DIAMOND.S4CC.Symbolics.COM bignums are bogus
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Apr 87 09:30:27 PDT
Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77351; Thu 16-Apr-87 12:29:18 EDT
Date: Thu, 16 Apr 87 12:29 EDT
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: bignums are bogus
To: sandra%orion@cs.utah.edu, common-lisp@sail.stanford.edu
Message-ID: <870416122902.2.DLA@LIMPKIN.S4CC.Symbolics.COM>
I always favored a pair of variables MOST-POSITIVE-BIGNUM and
MOST-NEGATIVE-BIGNUM. :-)
∂16-Apr-87 0946 RPG a lisp1 compatible subset of Common Lisp
∂15-Apr-87 1853 KMP@STONY-BROOK.SCRC.Symbolics.COM a lisp1 compatible subset of Common Lisp
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Apr 87 18:52:43 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 117173; Wed 15-Apr-87 21:49:13 EDT
Date: Wed, 15 Apr 87 21:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: a lisp1 compatible subset of Common Lisp
To: Masinter.pa@Xerox.COM
cc: RPG@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870327-152827-2635@Xerox>
Message-ID: <870415214810.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 27 Mar 87 15:31 PST
From: Masinter.pa@Xerox.COM
Subject: a lisp1 compatible subset of Common Lisp
To: RPG@SAIL.STANFORD.EDU, KMP@stony-brook.scrc.symbolics.com
I'm sending this to you becasue you two make up the lisp-1 vs lisp-2
committee. If others should be cc'd, please let me know.
Imagine a subset of Common Lisp, called Common-Lisp-Disjoint-space with
the following restrictions:
a) it is an error for a symbol to have both a symbol-function and a
symbol-value
b) function-type (i.e., function data type is separate from other types)
This should be done in any case.
c) lexical-global-scoping (i.e., the default for free, undeclared
variable references is that they are in the global lexical context, not
that they are dynamicly scoped).
This should be done in any case. I had dinner with Jonathan Rees tonight
and bugged him again to send out his proposal for proclaim-lexical.
d) it is an error to use a function or macro with the same name as a
lexical variable in the same lexical scope, i.e., to call list in a
lexical scope that binds the variable list. (Of course, this applies
even for those generated by macros.)
This is a subset such that:
1) a program which runs in the subset will run in full common lisp
(modulo the standard "portability" problems)
I mentioned at some point in the past and still believe that we should
actually define the term "subset" so that anyone claiming to have a subset
would have this property. This would keep one thing from being substituted
for another (eg, dynamic scoping for lexical scoping) while not disallowing
simple omissions.
In some trivial sense, I have no objection to anyone taking any dialect
which satisfies this criterion and calling it a CL subset. I do, however,
have an objection to extended subsets (where the extension is not
CL-compatible).
2) the "is an error" conditions imposed by the subset are enforcable,
either by dynamic runtime checking or by static compile-time analysis
I think that "is an error" is always valid to enforce. I think what you
want to say is that things claiming to be in this subset may not extend
these restrictions and still claim to be the subset.
Imagine a lisp-1 analogue of Common Lisp; I call it Common-Lisp-1-space.
This is the point at which I start to get worried about this. Much as the
Europeans are worried about our use of the string "Lisp" in the name
"Common Lisp" causing them problems when they try to do other lisps, I
worry about the use of the string "Common Lisp" in the name of anything
which is not claimed to be -the- Common Lisp. Perhaps I worry even a little
more in this case because the word "Common" was supposed to mean "Shared",
and in some sense you're suggesting a non-Shared Shared Lisp...
Its properties are as follows:
There is no symbol-function. Symbols have only one cell, symbol-value.
All places in CLtL which say symbol-function now say symbol-value. The
"function" special form is replaced as follows:
(function frob) => frob
(function (lambda ...)) => (lambda ...)
lambda is a new special form, which does what (function (lambda ...))
used to.
In the abstract, these are not unreasonable properties for a language to have.
I certainly understand what you're driving at.
- - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
Programs written in the subset Common-Lisp-Disjoint-space can by
converted mechanically to Common-lisp-1-space by defining
symbol-function = symbol-value, and defining function as a macro. Some
uses of funcall can be removed mechanically, although funcall is still
occasionally useful (e.g., (mapcar funcall list-of-functions
list-of-arguments)).
Well, not mechanically -- more like trivially. That is, you just add certain
functions to the environment --
(DEFUN FUNCTION (X) X)
(DEFMACRO LAMBDA (BVL &BODY FORMS) `#'(LAMBDA ,BVL ,@FORMS))
and things mostly work. Of course, this makes LAMBDA a macro, not a special
form. Also, it makes FUNCTION not be a special form.
The problem is that the name you've chosen is very long and no one wants to
program in a language with a long name. If you make the name shorter, it will
sound more like "Common Lisp" -- unless you remove a critical word like
"Common" or "Lisp" -- in which case the problem will be that it doesn't sound
enough like Common Lisp and so maybe no one will be interested in it.
Anyway, as long as it looks like Common Lisp, sounds like Common Lisp, etc.
it will drive a wedge into the pack of Common Lisp users, separating them
into separate camps. If there's one thing that is uppermost in importance,
I think, it is not to fragment the camps. CL was created with the explicit
purpose of eliminating the tower-of-babel effect in Lisp where no dialect
was able to talk to any other. I think it has done that well and we should
be careful not to destroy that.
I realize that the intent of your proposal is not to destroy it and that
you're trying to provide a peaceful way for people to coexist by allowing
them ways of saying that they want to program in a world that is neutral
about the issues that the Lisp1/Lisp2 folks are working out, but the problems
are that...
* The camp you're asking them to live in offers neither the features
of Lisp1 nor the features of Lisp2, and as such could be even more
burdensome to them than either of the two positions -- perhaps causing
some people to think Lisp is just too much hassle ... Lisp doesn't
need that kind of negative PR at this time, I think.
* I think that making the decision you want them to make involves users
understanding a lot more about the linguistic process than it is
appropriate to make them aware of ... Many people just don't care
about this issue a lot and we're starting to sound like the Christian
church trying to spawn a lot of denominations ... To most people it's
enough of a chore to decide that they belong to a major religion
such as Lisp, Scheme, PL1, or C. The subtle denominational differences
are something which is probably of more worry to us the clergy than it
is to the users.
* Making too many dialects which differ in ways that seem so subtle
is likely to fragment the community into a lot of little communities
who don't interact and for no good reason -- better we should just
insist that some agreement be reached. By allowing subsetting of this
kind, we allow ourselves to not really address the issues and we take
a statistical view on language design, observing after the fact what
people liked (and trying to infer why) rather than a more reasoned
approach.
* I think many people use Common Lisp because they don't want to have
to make decisions. There are AI researchers who got tired of tracking
the feature distinctions between the dialects and justifying to their
friends why they use dialect X instead of dialect Y. There are those
who just got tired and said: "Give me a dialect which people seem to
like and which I can use without feeling a need to justify myself.
It doesn't have to be the best dialect; it just has to be an obviously
reasonable dialect so I can just go out and learn it arbitrarily and
do work in it and forget about the meta issues of whether or why the
language works at all."
Some of these points seem to overlap. Oh well. I guess that means it's a
good point to stop.
I'm sorry these points took so long to conjure. I hope you find them useful.
∂16-Apr-87 1009 shebs%orion@cs.utah.edu Bognumosity
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 10:09:21 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA21692; Thu, 16 Apr 87 11:12:00 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA01398; Thu, 16 Apr 87 11:11:56 MDT
Date: Thu, 16 Apr 87 11:11:56 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8704161711.AA01398@utah-orion.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Bognumosity
It only hurts CL as a standard when people start talking about the "spirit"
of the specification as a substitute for precision. Some symbolic algebra
folks like really big numbers, starting at a "few thousand bits" and getting
bigger. Bignums can also be a good representation technique for certain
kinds of data structures (almost like bit vectors, but with different ops
available). Any vagueness on max size of bignums is no more acceptable
than it is for arrays or fixnums or floats, all of which have plenty of
constants defining *their* limits!
I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be
the largest value that INTEGER-LENGTH could return. It should be specifed
to be at least as large as MOST-POSITIVE-FIXNUM, with the usual exhortation
that "Implementors are encouraged to make this limit as large as practicable
without sacrificing performance." :-)
stan
∂16-Apr-87 1042 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: bignums are bogus
Received: from TUNNEL.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 16 Apr 87 10:41:38 PDT
Received: from aiva.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08755; 16 Apr 87 13:06 WET
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Thu, 16 Apr 87 14:04:58 GMT
Message-Id: <1827.8704161404@aiva.ed.ac.uk>
To: common-lisp@sail.stanford.edu, sandra <@cs.utah.edu:sandra@orion.arpa>
Subject: Re: bignums are bogus
> "Common Lisp in principle imposes no limit on the magnitude of an
> integer.
Note "in principle".
> I don't know of any machine that has an infinitely large amount of memory,
> or even an infinitely large address space.
Practical limits of this sort also apply to things like the maximum number
of conses, the maximum length of a list, etc. Presumably, you don't think
lists are bogus...
> I expect some implementations of bignums have other constraints as well:
> assuming the number of bigits is a fixnum, storing the bigits in an array
> (limiting the number of bigits to the maximum array size), or similar
> representation-related problems.
Well, if the representation imposes a limit lower than that imposed by
the total storage available we might be justified in saying it is not a
correct implementation. Of course, we would only be inclined to do this
if the lower limit was relatively small (e.g. number of bigits in a byte).
Now I suppose there'll be hundreds of these messages (at least as many as
about compiling CASE).
∂16-Apr-87 1054 FAHLMAN@C.CS.CMU.EDU Bognumosity
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 10:54:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 16 Apr 87 13:44:06-EDT
Date: Thu, 16 Apr 1987 13:43 EDT
Message-ID: <FAHLMAN.12295009436.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: shebs%orion@λcs.utah.edu (Stanley T. Shebs)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Bognumosity
In-reply-to: Msg of 16 Apr 1987 13:11-EDT from shebs%orion at cs.utah.edu (Stanley T. Shebs)
Any vagueness on max size of bignums is no more acceptable
than it is for arrays or fixnums or floats, all of which have plenty of
constants defining *their* limits!
I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be
the largest value that INTEGER-LENGTH could return.
Presumably, then we also need a constant called CONS-LIMIT, which is the
maximum allowable length of any list. After all, someone might want to
use a list of T's and NIL's instead of a bit vector, and it weakens the
standard if we don't tell him exactly how long this list can be.
What we do if someone creates two of these maximum-length lists, or a
maximum-length list of maximum-length lists, I don't know, but we had
better decide, since it will weaken the standard if we are vague about
what is allowed here. Let's just say that every legal Common Lisp must
have at least N cons cells available to the user at all times, no matter
what he may have used so far, or else it is not a legal Common Lisp. N
should be at least a million. Or maybe N should be seven.
A sufficiently tight standard will have no instances.
Maybe the scope of the smiley face at the end of your message was meant
to be the whole message?
-- Scott
∂16-Apr-87 1124 KMP@STONY-BROOK.SCRC.Symbolics.COM bignums are bogus, but so are fixnums
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87 11:24:17 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 117743; Thu 16-Apr-87 14:24:16 EDT
Date: Thu, 16 Apr 87 14:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: bignums are bogus, but so are fixnums
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU, RAM@C.CS.CMU.EDU,
sandra%orion@cs.utah.edu, DCP@QUABBIN.SCRC.Symbolics.COM
In-Reply-To: <FAHLMAN.12294960256.BABYL@C.CS.CMU.EDU>
Message-ID: <870416142310.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[Removed Common-Lisp, and added CL-Cleanup for sake of flame control.]
While we're on the subject, I think CLtL is ambiguous on whether
you're required to have a non-zero number of either bignums or
fixnums. That is, if you use a uniform representation for integers,
I think it's unclear whether you can arbitrarily choose to call them
either fixnums or bignums.
If you choose to call all integers bignums, then I'm not completely
clear on what the value of MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM
should be, since I bet most code assumes that the
(THE FIXNUM MOST-POSITIVE-FIXNUM)
is not an error.
If you choose to call all integers fixnums, then it's not clear what
to set MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM to, since there
may not be an upper bound. For example, adding another piece of memory
or disk may allow you to dynamically change the value. Also, presumably,
your entire Lisp image would be taken up by representing this value.
Also, it isn't made clear that if you choose to have fixnums that
zero must be one. If you choose your fixnum range to be 500-650,
then it seems clear that MOST-NEGATIVE-FIXNUM should be 500 because
it's a fixnum and because of all the fixnums, it's the most negative
(though in fact it's not negative at all). I think this would surprise
some programs, though. In fact, if the range were completely negative,
then MOST-POSITIVE-FIXNUM might be negative. To see the problems you
can get into, consider the following code which I once wrote for
some fairly obscure application... I needed a count of the number of
possible fixnums for some obscure reason and I did
(+ (- MOST-NEGATIVE-FIXNUM) ; Assume this value is negative.
1 ; Account for 0
MOST-POSITIVE-FIXNUM) ; Assume this value is positive.
I suppose I should have done
(+ (- MOST-POSITIVE-FIXNUM MOST-NEGATIVE-FIXNUM) 1)
I guess I was afraid of the fencepost problems in this. In any
case, this doesn't even work unless an implementation with no fixnums
is careful to pick MOST-POSITIVE-FIXNUM to be something like -1
and MOST-NEGATIVE-FIXNUM to be 0 so that they sum to -1. If you choose
them both to be 0, which would seem most obvious to me, then my code
would probably guess that there was 1 fixnum (and a human onlooker
would probably infer that the one fixnum was 0).
I imagine there's an analagous set of hassles that can come up, for
example, if short floats represent a range of numbers that don't contain
a value appropriate for SHORT-FLOAT-EPSILON, or whatever.
These are not just mental exercises. I vaguely remember a while back
reviewing specs for various CL implementations we were considering
as targets for Macsyma and running across at least one that had some
of the aforementioned problems, which is what got me thinking about
this issue in the first place...
Some careful thought about whether these variables should be allowed
to contain NIL when some other value would be meaningless or
computationally impractical is probably in order.
∂16-Apr-87 1211 shebs%orion@cs.utah.edu Re: Bognumosity
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 12:11:42 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA28433; Thu, 16 Apr 87 13:14:17 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA01837; Thu, 16 Apr 87 13:14:13 MDT
Date: Thu, 16 Apr 87 13:14:13 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8704161914.AA01837@utah-orion.ARPA>
To: Fahlman@c.cs.cmu.edu, shebs%orion@λcs.utah.eduλ
Subject: Re: Bognumosity
Cc: common-lisp@sail.stanford.edu
Any vagueness on max size of bignums is no more acceptable
than it is for arrays or fixnums or floats, all of which have plenty of
constants defining *their* limits!
I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be
the largest value that INTEGER-LENGTH could return.
Presumably, then we also need a constant called CONS-LIMIT, which is the
maximum allowable length of any list. After all, someone might want to
use a list of T's and NIL's instead of a bit vector, and it weakens the
standard if we don't tell him exactly how long this list can be.
That's part of my thesis work, so I won't insist on it being in the standard
right now! A CONS-LIMIT of some sort would be necessary in a Lisp system
that produces programs for embedded systems, however, so it's not as
ridiculous as it appears to be...
Maybe the scope of the smiley face at the end of your message was meant
to be the whole message?
Sorry, I was quite serious. If bignum size limits are silly, then why are
array size limits not silly? Seems inconsistent.
Here's a (serious) meta-proposal: every type of potentially unbounded
size must have limit parameters. This would include arrays of all types,
numbers (both floats and rationals), packages, random states, compiled code,
hash tables, and structures. There wouldn't be any need for a CONS-LIMIT,
because individual conses are always the same size, and a possible LIST-LIMIT
would not be meaningful, because LIST is (OR CONS NULL).
Right now the only limits are on arrays, fixnums, and floats, so there would
be a lot of extra parameters. On the other hand, I've observed some rather
wild variation in the number of bits in a random state, which affects the
quality of random number generation. An unlucky user of packages may find
that a package is implemented with a hash table, which is implemented with
an array, which has an ARRAY-DIMENSION-LIMIT of 1024, limiting the total
number of symbols in a package to that many. I'm sure we're all familiar
with the sort of terminology that users apply to implementors when tricks
like this come to light...
Anyway, if all this is stupid, let me know and I'll shut up.
stan
∂16-Apr-87 1216 DALY@IBM.COM typos in Cltl
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 12:16:34 PDT
Date: 16 April 1987, 14:48:02 EDT
From: Timothy Daly <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <041687.144803.daly@ibm.com>
Subject: typos in Cltl
There is a typo on p 277.
The line reads:
((a b) #(f 3) ....
it should read
(#(a b) #(f 3) ....
the dispatching macro character is missing.
I didn't see this one in the list of typos dated 12/85.
Is there a later one?
∂16-Apr-87 1237 hoey@nrl-aic.ARPA Re: Bognumosity
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87 12:37:30 PDT
Return-Path: <hoey@nrl-aic.ARPA>
Received: Thu, 16 Apr 87 14:37:44 est by nrl-aic.ARPA id AA21715
Date: 16 Apr 1987 14:19:04 EST (Thu)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: Bognumosity
To: common-lisp@sail.stanford.edu
Message-Id: <545599144/hoey@nrl-aic>
Date: Thu, 16 Apr 87 11:11:56 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8704161711.AA01398@utah-orion.ARPA>
To: common-lisp@sail.stanford.edu
I think we should introduce an INTEGER-LENGTH-LIMIT constant which
would be the largest value that INTEGER-LENGTH could return. It
should be specifed to be at least as large as
MOST-POSITIVE-FIXNUM....
Simpler would be to use ARRAY-TOTAL-SIZE-LIMIT for this value. This is
based on the duality of bignums and bit vectors. If implementors then
want to represent bignums in some silly way that restricts them, they
can then reduce their advertised ATSL (but not below 1024).
I think a Lisp with 1K-bit bignums would be about as unusable as a lisp
with 1K-element arrays.
Dan
∂16-Apr-87 1310 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Bognumosity
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 16 Apr 87 13:10:02 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72653; Thu 16-Apr-87 16:09:51 EDT
Date: Thu, 16 Apr 87 16:06 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Bognumosity
To: shebs%orion@cs.utah.edu, Fahlman@CMU-CS-C.ARPA
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8704161914.AA01837@utah-orion.ARPA>
Message-ID: <870416160605.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 16 Apr 87 13:14:13 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
There wouldn't be any need for a CONS-LIMIT,
because individual conses are always the same size,
But what if I wanted to write a program for, as you say, an embedded
system, and I needed to know exactly how many cons cells I can create
and be quite certain that I won't run out of memory? Conversely, if I
know what the bignum limit is, and I stay within that limit, but make
zillions of such legal bignums, then I might run out of virtual memory.
So whether the individual object is of fixed size or of variable size
doesn't really matter, for the purposes you're referring to.
∂16-Apr-87 1317 sdcrdcf!darrelj@CS.UCLA.EDU Re: bignums are bogus
Received: from CS.UCLA.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 13:17:25 PDT
From: sdcrdcf!darrelj@CS.UCLA.EDU
Received: by sdc.uucp (4.12/sdcrdcf)
id AA05609; Thu, 16 Apr 87 12:54:57 pst
Message-Id: <8704162054.AA05609@sdc.uucp>
Received: from XAVIER by sdcrdcf with PUP; Thu, 16 Apr 87 12:54 PST
Date: 16 Apr 87 12:59 PDT (Thursday)
Subject: Re: bignums are bogus
In-Reply-To: sdcjove!cs.utah.edu!sandra%orion (Sandra J Loosemore)'s message of Thu, 16 Apr 87 00:01:04 MDT
To: sdcjove!cs.utah.edu!sandra%orion (Sandra J Loosemore)
Cc: common-lisp%sail.stanford.edu
You could always take the approach that Xerox did. Implement bignums
in such an inefficient way that processing time grows to unacceptable
levels before representation limits are anything close to reached!
(Actually I only see a few possibilities for representation: a list of
fragments [Xerox uses lists of 14 bit components]; arrays of
fragments; or something your hardware supports which is sort of large:
e.g. 128 bit floating or 31 digit packed decimal on IBM 370s, 99 digit
decimal on Symbol-IIR, etc. The first two could be expected to
support a million bits on almost anything from an IBM PC upwards.
Operation time and "consing" overhead would be pretty grim. Only the
array case might have an obvious hard upper bound. The third case
would certainly verge on "broken" by almost any reasonable standards.
Darrel
∂16-Apr-87 1349 @SAIL.STANFORD.EDU:REM@IMSSS How much memory for bignum or other large data structure?
Received: from SAIL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 13:49:24 PDT
X-Date-last-edited: 1987 April 16 12:48:04 PST (=GMT-8hr)
From: Robert Elton Maas <REM%IMSSS@SAIL.Stanford.EDU>
To:common-lisp@SAIL.STANFORD.EDU
CC:hoey@nrl-aic.ARPA
Subject:How much memory for bignum or other large data structure?
<RAM> Date: Thu, 16 Apr 1987 10:27 EDT
<RAM> From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
<RAM> The problem with running out of storage has no special relation to
<RAM> bignums of course. Some programs may require data structures larger
<RAM> than some implementations can support on a given hardware
<RAM> configuration. This is a potential portability problem, but I see
<RAM> nothing that can be done about it.
I do. A program can be aware of how close it is getting to using all
available memory (address space, swap space, etc.) by means of calls
to the LISP (CL) system, and adjust its behaviour accordingly to avoid
actually reaching the absolute limit. In this way a program can
effective utilize virtually all the memory available on any given
machine at any given time, instead of setting some arbitrary portable
limit on memory usage which may be far below that actually available.
Several kinds of programs run better the more memory they actually
use. Examples are: (1) Sort/merge, the more data that can be sorted in
memory, the larger sorted-segments can be emitted from the first pass
and the fewer disk-passes needed to merge the sorted-segments into a
single sorted-segment; (2) Any planning/lookahead program such as game
playing or robotics, the more data that can be stored in a tree
structure or hash table representing choices already analyzed, the
further ahead the program can look without having to recompute the
same choices over and over again, and thus the better "intelligence"
the program can exhibit.
In addition to parameters on particular data types that determine
their limits because of internal representation, every LISP
implementation should provide a way for a running program to ask how
much memory is remaining not currently in use (or in a system with
different kinds of data in different kinds of memory, how much memory
of a particular kind is not currently not in use). A program could ask
once, and if the answer comes back too small then force a
garbage-collect-completion and ask again, and if the answer is still
too small the program truncates its expansion at that point.
This facility is crucial enough for the kinds of "artificial
intelligence" programs typical of LISP, and is trivial enough to
implement in the underlying LISP system and virtually impossible to
hack up by user-level programming, that it should be a *required*
feature of every implementation, i.e. should be in the CL standard.
<RAM> Perhaps Common Lisp should specify a minimum maximum size for bignums
<RAM> and require that an error be signalled if this is ever exceeded. I
<RAM> would guess that a limit of a few thousand bits would meet every use
<RAM> except the most common, namely impressing non-lispers by typing
<RAM> (FACT 1000) and getting screens full of digits.
If the limit is representational, then indeed an
implementation-dependent largest-size-allowed parameter should be
provided by the system. If the limit is due to total memory use, any
system query specifically regarding bignums would have to use the
memory-remaining information to compute the bignum-that-would-fit
information, to account for memory already used and hence not
available. For the factorial hack, the toplevel FACT function could
first approximate the factorial by logarithms, check to see whether
there is enough memory for that data, and if not then complain and
advise the user what the maximum workable argument to FACT currently is.
<DLA> Date: Thu, 16 Apr 87 12:29 EDT
<DLA> From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
<DLA> I always favored a pair of variables MOST-POSITIVE-BIGNUM and
<DLA> MOST-NEGATIVE-BIGNUM. :-)
Of course if this is based on memory available, only one of the two
could exist at any time, and as soon as it existed it would contradict
itself because there'd be no room left for the bignum you really
wanted. (This explanation is in case anybody didn't fully get the joke.)
<STS> Date: Thu, 16 Apr 87 13:14:13 MDT
<STS> From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
<STS> Here's a (serious) meta-proposal: every type of potentially unbounded
<STS> size must have limit parameters. This would include arrays of all types,
<STS> numbers (both floats and rationals), packages, random states,
<STS> compiled code, hash tables, and structures. There wouldn't be any
<STS> need for a CONS-LIMIT, because individual conses are always the same
<STS> size, and a possible LIST-LIMIT would not be meaningful, because LIST
<STS> is (OR CONS NULL).
I second that proposal (see the first part of my message) with
amendment (clarification) that these limit parameters refer to
representation rather than memory available. For example, if BIGNUMs
are implemented in a recursive way, there may be no limit on their
size whatsoever other than memory available, and some extremely
gigantic but sparse BIGNUMs may in fact be representable while some
smaller ones that aren't sparse wouldn't; in such a case the limit
parameter would be INFINITY. But if the number-of-digits of a BIGNUM
is a FIXNUM, then there's an absolute representational limit which is
given in the proposed limit parameter. -- In addition to these limit
parameters, of course, is my proposal for runtime memory-not-yet-used query.
<STS> Right now the only limits are on arrays, fixnums, and floats, so
<STS> there would be a lot of extra parameters.
Yes, but compared to the total memory available the limit parameters
would be insignificant in size, thus no problem.
<DH> Date: 16 Apr 1987 14:19:04 EST (Thu)
<DH> From: Dan Hoey <hoey@nrl-aic.ARPA>
<DH> Simpler would be to use ARRAY-TOTAL-SIZE-LIMIT for this value.
I don't understand this proposal. If all arrays are stored in some
special place in memory, that limits their total size without being
affected by CONSs consuming memory elsewhere, that would make sense.
Or do you mean the total number of elements in a single array of
multiple dimensions (axes) because of a machine limit on the size of
an index register? Please clarify?
∂16-Apr-87 1354 shebs%orion@cs.utah.edu Re: Bognumosity
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 13:54:13 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA03494; Thu, 16 Apr 87 14:56:23 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA02607; Thu, 16 Apr 87 14:56:17 MDT
Date: Thu, 16 Apr 87 14:56:17 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8704162056.AA02607@utah-orion.ARPA>
To: DLW@alderaan.scrc.symbolics.com, Fahlman@cmu-cs-c.arpa,
shebs%orion@cs.utah.edu
Subject: Re: Bognumosity
Cc: common-lisp@sail.stanford.edu
In case it wasn't clear, I was *not* trying to address the issue of the
relation between number/size of objects and size of memory available. I'm
well aware that there are many problems, *and* very little research on them
(if anybody knows of anything, I want to hear about it). I shouldn't have
said anything about embedded systems, they're irrelevant.
What can and should be done is to formalize the limitations that implementors
wire into the representations of data objects. Those limits will be there
no matter how much or how little memory is available, since they have to
do with the bit patterns of data structures. If you have a program that
wants a 1025 element array in a Lisp that limits arrays to 1024 elements,
making the heap bigger isn't going to help.
stan
∂16-Apr-87 1403 preece%mycroft@gswd-vms.ARPA Re: Bognumosity
Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87 14:02:44 PDT
Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/)
Message-Id: <8704162101.AA04269@gswd-vms.ARPA>
Date: Thu, 16 Apr 87 15:00:04 CST
From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@sail.stanford.edu
Subject: Re: Bognumosity
Fahlman@C.CS.CMU.:
stanley shebs:
>> I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be
>> the largest value that INTEGER-LENGTH could return.
> Presumably, then we also need a constant called CONS-LIMIT, which is the
> maximum allowable length of any list. After all, someone might want to
> use a list of T's and NIL's instead of a bit vector, and it weakens the
> standard if we don't tell him exactly how long this list can be.
>
> What we do if someone creates two of these maximum-length lists, or a
> maximum-length list of maximum-length lists, I don't know, but we had
> better decide, since it will weaken the standard if we are vague about
> what is allowed here.
----------
The problem is that that is exactly what the limits DON'T do -- they
don't guarantee that at any given moment the biggest array you can create
is size x. I don't really think the various limits already provided
are worth much. Once in a while they may allow someone to decide
early on that porting a particular application to a particular
implementation is infeasible (because it uses arrays, or whatever, that
are bigger than a limit), but it can never give much assurance that
an application which does respect the limits is portable to a
particular implementation, since at any given moment there may not
be space available to allocate an object, even though it of legal
size for the implementation.
The implementor is left with the problem of deciding what to advertise
as the limits for her particular implementation. What will users
care about? The largest array that can be allocated on an empty
system with maximum memory? The largest array that can be allocated
on an empty system with the smallest memory configuration sold? The
largest array that can be allocated with memory in a "typical"
configuration and already populated with a "typical" amount of
pre-existing stuff? What's typical?
Adding more limits doesn't seem to me to be very useful.
--
scott preece
gould/csd - urbana
uucp: ihnp4!uiucdcs!ccvaxa!preece
arpa: preece@gswd-vms
∂16-Apr-87 1411 preece%mycroft@gswd-vms.ARPA Re: Bognumosity
Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87 14:10:01 PDT
Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/)
Message-Id: <8704162108.AA04289@gswd-vms.ARPA>
Date: Thu, 16 Apr 87 15:00:04 CST
From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@sail.stanford.edu
Subject: Re: Bognumosity
Fahlman@C.CS.CMU.:
stanley shebs:
>> I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be
>> the largest value that INTEGER-LENGTH could return.
> Presumably, then we also need a constant called CONS-LIMIT, which is the
> maximum allowable length of any list. After all, someone might want to
> use a list of T's and NIL's instead of a bit vector, and it weakens the
> standard if we don't tell him exactly how long this list can be.
>
> What we do if someone creates two of these maximum-length lists, or a
> maximum-length list of maximum-length lists, I don't know, but we had
> better decide, since it will weaken the standard if we are vague about
> what is allowed here.
----------
The problem is that that is exactly what the limits DON'T do -- they
don't guarantee that at any given moment the biggest array you can create
is size x. I don't really think the various limits already provided
are worth much. Once in a while they may allow someone to decide
early on that porting a particular application to a particular
implementation is infeasible (because it uses arrays, or whatever, that
are bigger than a limit), but it can never give much assurance that
an application which does respect the limits is portable to a
particular implementation, since at any given moment there may not
be space available to allocate an object, even though it of legal
size for the implementation.
The implementor is left with the problem of deciding what to advertise
as the limits for her particular implementation. What will users
care about? The largest array that can be allocated on an empty
system with maximum memory? The largest array that can be allocated
on an empty system with the smallest memory configuration sold? The
largest array that can be allocated with memory in a "typical"
configuration and already populated with a "typical" amount of
pre-existing stuff? What's typical?
Adding more limits doesn't seem to me to be very useful.
--
scott preece
gould/csd - urbana
uucp: ihnp4!uiucdcs!ccvaxa!preece
arpa: preece@gswd-vms
∂16-Apr-87 1419 edsel!bhopal!jonl@navajo.stanford.edu bignums are bogus
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 14:19:12 PDT
Received: by navajo.stanford.edu; Thu, 16 Apr 87 14:18:18 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA01743; Thu, 16 Apr 87 13:03:36 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA10792; Thu, 16 Apr 87 14:00:34 PDT
Date: Thu, 16 Apr 87 14:00:34 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704162100.AA10792@bhopal.edsel.com>
To: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: David L. Andre's message of Thu, 16 Apr 87 12:29 EDT
Subject: bignums are bogus
re: I always favored a pair of variables MOST-POSITIVE-BIGNUM and
MOST-NEGATIVE-BIGNUM. :-)
As silly as this may sound, I actually ran up against this. Really!
It turns out that most implementations have the bignum's length stored
in some field of fixed size (say, n bits). I accidentally computed up
such an item on a 3600 about a year or so ago (while writing the
"bignum" paper for the 1986 Lisp conference). It seemed as though
the computation was taking far too long. Ultimately, I tracked it down
to the fact that the ephemeral GC couldn't find enough space to copy
the fool thing (even though it had been created), so it fell into the
debugger, and was trying to print out this loser for me. In base 10!
-- JonL --
P.S. It never finised the base-10-conversion process.
∂16-Apr-87 1426 FAHLMAN@C.CS.CMU.EDU bignums are bogus, but so are fixnums
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 14:26:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 16 Apr 87 17:12:21-EDT
Date: Thu, 16 Apr 1987 17:11 EDT
Message-ID: <FAHLMAN.12295047205.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU, DCP@SCRC-QUABBIN.ARPA, RAM@C.CS.CMU.EDU,
sandra%orion@CS.UTAH.EDU
Subject: bignums are bogus, but so are fixnums
In-reply-to: Msg of 16 Apr 1987 14:23-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Some careful thought about whether these variables should be allowed
to contain NIL when some other value would be meaningless or
computationally impractical is probably in order.
Fine, this is under-specified and should be cleaned up. My opinion is
that this is deeply unimportant and should be considered last, after
every other issue raised to date has been settled. I just don't lie
awake nights thinking about what the fixnum limit constants should be
fore implementations in which the fixnum range is 500 to 570.
If you think this issue deserves a higher priority, feel free to submit a
definite proposal for how to clean it up.
-- Scott
∂16-Apr-87 1511 Masinter.pa@Xerox.COM bignums are bogus
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 15:10:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 APR 87 15:10:31 PDT
Date: 16 Apr 87 15:14 PDT
From: Masinter.pa@Xerox.COM
Subject: bignums are bogus
In-reply-to: various
cc: common-lisp@sail.stanford.edu
Message-ID: <870416-151031-1512@Xerox>
The only practical way I know of dealing with storage limits and the
like in a programmatic way is to treat reaching them as well defined
exceptional situations which signal conditions. Programs that care, such
as those in embedded systems, can catch those exceptional situations and
do something reasonable with them, whether it is a bignum storage
overflow or running out of CONS space.
This is addressed in part in the exceptional-situations-in-Lisp
proposal, which is still (apparently) in committee.
∂16-Apr-87 1513 hoey@nrl-aic.ARPA Re: How much memory for bignum or other large data structure?
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87 15:12:57 PDT
Return-Path: <hoey@nrl-aic.ARPA>
Received: Thu, 16 Apr 87 17:12:59 est by nrl-aic.ARPA id AA22340
Date: 16 Apr 1987 16:16:36 EST (Thu)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: How much memory for bignum or other large data structure?
To: Robert Elton Maas <REM%IMSSS@SAIL.Stanford.EDU>
Message-Id: <545606196/hoey@nrl-aic>
In-Reply-To: Robert Elton Maas's message of Thu, 16 Apr 87 154955 est
Cc: common-lisp@sail.stanford.edu
Date: Thu, 16 Apr 87 15:49:55 est
From: Robert Elton Maas <REM%IMSSS@SAIL.Stanford.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Cc: hoey@nrl-aic.ARPA
A program can be aware of how close it is getting to using all
available memory (address space, swap space, etc.) by means of calls
to the LISP (CL) system, and adjust its behaviour accordingly to avoid
actually reaching the absolute limit.
The hard part is actually defining portably how to do this. I can
imagine it might be hard for some systems to implement a function to
answer ``I want to make 50 100k-bit bignums, 100 10k fixnum-arrays, and
maybe 10K of conses, is there space?''. Comments from implementors?
Maybe the function should take a key like :VERY-MUCH to request GC if
necessary.
Then again, a negative answer to this query might be less than useful
if the reason is that the system doesn't support 10k fixnum arrays.
And I don't favor adding a ton of hair to allow the system to answer
some of the fine-grained questions Maas proposes. In particular
<STS> ... there would be a lot of extra parameters.
Yes, but compared to the total memory available the limit parameters
would be insignificant in size, thus no problem.
I'm concerned about the space consumed in the bookshelf and interaural
areas.
<DH> Date: 16 Apr 1987 14:19:04 EST (Thu)
<DH> From: Dan Hoey <hoey@nrl-aic.ARPA>
<DH> Simpler would be to use ARRAY-TOTAL-SIZE-LIMIT for this value.
I don't understand this proposal.
I was not proposing addition of runtime-related storage information,
because that has so far remained outside of CL's scope (unless someone
out there actually has MAKE-ARRAY (and CONS?) side-effect
ARRAY-TOTAL-SIZE-LIMIT). What I advocate is that *if* some
implementation has a representational limit on BIGNUMS, it should be
required to provide it. And rather than add the 776th symbol to LISP
(we may be running out!), I suggested using the same limit that
guarantees the size of a bit vector. The system may be able to make a
larger bignum than ARRAY-TOTAL-SIZE-LIMIT, but the same is true of bit
vectors. What I want the parameters for is to determine whether a
given implementation is a toy or a system.
Dan
∂16-Apr-87 1517 Pavel.pa@Xerox.COM Re: typos in Cltl
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 15:17:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 APR 87 15:14:24 PDT
Date: 16 Apr 87 15:14 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: typos in Cltl
In-reply-to: Timothy Daly <DALY@ibm.com>'s message of 16 April 1987,
14:48:02 EDT
To: DALY@ibm.com
cc: common-lisp@sail.stanford.edu
Message-ID: <870416-151424-1516@Xerox>
That example isn't a typo. Note that the list (a b) is a member of the
second argument to UNION. This fact is even brought out specifically in
the text as a reason to use :test-not #'mismatch instead of :test
#'equalp.
Pavel
∂16-Apr-87 1605 sandra%orion@cs.utah.edu bugnums (er, bignums)
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 16:04:50 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA10150; Thu, 16 Apr 87 17:07:29 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA03261; Thu, 16 Apr 87 17:07:25 MDT
Date: Thu, 16 Apr 87 17:07:25 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8704162307.AA03261@utah-orion.ARPA>
Subject: bugnums (er, bignums)
To: common-lisp@sail.stanford.edu
I realize that running out of memory is a more general problem, and in fact
my main concern in bring this issue up was the representation issue and the
fact the CLtL defines constants and states (or recommends) minimum values
for the sizes of other kinds of objects, such as arrays and floats.
If, as some people have pointed out, having a stated limit on integer
size would be silly because "there's nothing you can do once you run out
of memory anyway" (or comments to that effect), than it is equally silly
to specify limits on the size of these other objects.
I am *not* proposing any minimum limits on the *number* of objects an
implementation can support: this is purely an issue of the *size* of a
single object.
As a secondary issue, I thought that clarifying the semantics of integer
overflow might be useful to those of us working with small implementations
on small machines; in my case, a M68K box with a meg of memory. It's
unlikely that I'd be able to fit a full CL on this machine and I think
that there are other features far more important to the "spirit" of the
spec than support for huge bignums. (I'm all for adhering to the "spirit"
of the spec, particularly since I don't have much chance of adhering to
the letter!) The point is, I can make anybody's bignum implementation
overflow, whether the maximum number of bits I can have is 32 or
most-positive-fixnum. It just happens a lot more often if the limit is 32.
Incidentally, I can think of a few other potential problems with trying
to allocate large objects, other than the obvious representation or
running-out-of-memory problems. For example, your operating system may
impose a limit on the size of contiguous memory block you can snarf up.
(I've already run into this using a C compiler with 16 bit ints -- malloc
takes an "int" sized argument....) Or, your Lisp compiler may assume
that 16 bits is sufficient to represent the displacement used for
indexing into an array.
-Sandra
-------
∂16-Apr-87 1632 ghenis.pasa@Xerox.COM SOME and Multiple Values
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 16:32:01 PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 16 APR 87 16:33:00 PDT
Date: 16 Apr 87 16:31 PDT
From: ghenis.pasa@Xerox.COM
Subject: SOME and Multiple Values
To: common-lisp@sail.stanford.edu
Message-ID: <870416-163300-1658@Xerox>
Is it reasonable to expect SOME to return multiple values? CLtL says:
"SOME returns as soon as any invocation of predicate returns a non-nil
value. SOME returns that value."
What if the predicate returns multiple values?
Meta-question: As a matter of current semantics, are multiple values
mandatory only when the standard EXPLICITLY says so?
∂16-Apr-87 1652 Masinter.pa@Xerox.COM Uncle Lisp Needs You
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 16:52:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 APR 87 16:53:36 PDT
Date: 16 Apr 87 16:57 PDT
From: Masinter.pa@Xerox.COM
Subject: Uncle Lisp Needs You
To: cl-cleanup@sail.stanford.edu
Message-ID: <870416-165336-1679@Xerox>
If you would like to have some of the proposals we have before us
actually GET VOTED ON at the next X3J13 meeting, rather than merely
enjoying the intellectual stimulation of discussing them, it is
necessary for you (collectively) to VOLUNTEER (or find someone to
volunteer) to actually work on writing up/editing the proposals we have.
Scott has promised to take a few on in the next week. I need more.
Please.
∂16-Apr-87 1703 pyramid!pyramid.UUCP!bein@hplabs.HP.COM Re: Bognumosity
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 17:03:09 PDT
Received: by hplabs.HP.COM ; Thu, 16 Apr 87 14:32:00 pst
Received: from manpyrnova
by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86)
id AA12155; Thu, 16 Apr 87 14:51:24 PDT
Received: by pyrnova.pyramid.COM (5.52/UUCP-Project/rel-1.0/09-11-86)
id AA23093; Thu, 16 Apr 87 14:51:11 PDT
Date: 16 Apr 1987 14:44 PDT
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: Re: Bognumosity
To: hplabs!common-lisp@sail.stanford.edu@hplabs.HP.COM
Message-Id: <545606488/bein@pyrnova>
Stan:
I agree with the spirit of essentially unlimited size bignums. On
most of the systems I know of, most-positive-fixnum is 27 bits or more,
implying that a bignum that long would take at least 16 megabytes to
represent unless one is willing to introduce a notion like floating
point where low order bits are not represented beyond some limit,
at which point why not use floating point to begin with. My system
in fact adheres roughly to your suggestion, where technically a
bignum 134217702 bits long can be allocated (most-positive-fixnum is
134217727 in my system). I think you'll find that doing anything
with a bignum that long is next to impossible since other resources
like scratch stack space may not accomodate multiple copies of something
that large (which of course is not very interesting when it happens).
I would almost suggest that if there is a limit, it be tied to
notions like the largest float since a larger bignum can't be converted
properly unless we introduce notions like floating-infinities into the
language. If we do that however, we end up needing a definition for
rational infinity. I don't have a good handle on what infinity means
from an operational point of view. Maybe getting out of digit computers
for a while would help -- :-)
I too am uncomfortable with the idea that rational numbers overflow,
but don't have any practical ideas about what do besides treat the
problem as simply a resource problem which is what I am already doing.
--David
∂16-Apr-87 1703 ghenis.pasa@Xerox.COM SETF and pathname slots
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 17:03:10 PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 16 APR 87 17:03:08 PDT
Date: 16 Apr 87 17:01 PDT
From: ghenis.pasa@Xerox.COM
Subject: SETF and pathname slots
To: common-lisp@sail.stanford.edu
Message-ID: <870416-170308-1688@Xerox>
Should the standard require SETF to handle pathname slots? If we are
going to have MAKE-PATHNAME, PATHNAME-DEVICE, etc, for consistency we
should also have COPY-PATHNAME and be able to do things like (SETF
(PATHNAME-TYPE old-path) "OLD"). Is there any reason not to?
∂16-Apr-87 1736 FAHLMAN@C.CS.CMU.EDU SOME and Multiple Values
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 17:35:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 16 Apr 87 20:37:18-EDT
Date: Thu, 16 Apr 1987 20:37 EDT
Message-ID: <FAHLMAN.12295084669.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: ghenis.pasa@XEROX.COM
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: SOME and Multiple Values
In-reply-to: Msg of 16 Apr 1987 19:31-EDT from ghenis.pasa at Xerox.COM
Is it reasonable to expect SOME to return multiple values? CLtL says:
"SOME returns as soon as any invocation of predicate returns a non-nil
value. SOME returns that value."
What if the predicate returns multiple values?
No, for the same reason that OR returns only a single value for clauses
other than the last one. That is, the implicit NULL test "consumes" the
values returned from the predicate, discarding all but the last one.
-- Scott
∂16-Apr-87 1917 diamant%hpfclp@hplabs.HP.COM Re: CLARIFICATION: [italics]package arguments.
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 19:17:10 PDT
Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Thu, 16 Apr 87 14:21:15 pst
Received: by hpfclp.HP.COM; Thu, 16 Apr 87 16:20:21 mst
Date: Thu, 16 Apr 87 16:20:21 mst
From: John Diamant <diamant%hpfclp@hplabs.HP.COM>
Return-Path: <diamant@hpfclp>
Message-Id: <8704162320.AA08469@hpfclp.HP.COM>
To: vrotney@vaxa.isi.edu
Cc: common-lisp@sail.stanford.edu
Subject: Re: CLARIFICATION: [italics]package arguments.
> Are the package functions that take a package argument in CLTL with
> the name [italics]package allowed to have a string or symbol as that
> argument? If so, HP take note, we had to make a lot of changes in our
> Symbolics generated code to make it port to CL on the HPAIWS. If not,
> then why not?
No, they aren't. We looked very carefully in Steele for an indication that
they were allowed, but they aren't. It quite clearly states on most
of these functions that "The argument must be a package." A name of a
package is not a package. The problem with being "nice" by stretching what
the standard says is exactly the problem you have. If, as I believe from
my reading of Steele, package names are not allowed, then Symbolics is
violating the standard, and thus lulling people into writing non-portable
code (as you did). We opted for a strict interpretation, because code
developed on our machines will have a much better chance of being portable.
Besides, if standard doesn't say what people want it to say, then it should
be changed -- that doesn't mean language developers should ignore the
standard because they don't like it.
By the way, I don't know of any reason why the package functions couldn't
take a name as well (except that for package-name, it wouldn't make much
sense).
John Diamant
∂16-Apr-87 2012 DON%atc.bendix.com@RELAY.CS.NET Bignums are bogus?
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Apr 87 20:11:59 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac19928; 16 Apr 87 23:07 EDT
Received: from atc.bendix.com by RELAY.CS.NET id ab18198; 16 Apr 87 23:04 AST
Date: Thu, 16 Apr 87 15:33 EDT
From: DON%atc.bendix.com@RELAY.CS.NET
Subject: Bignums are bogus?
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"common-lisp@sail.stanford.edu"
>From: IN%"Rob MacLachlan <RAM@c.cs.cmu.edu>" 16-APR-1987 12:52
>To: Sandra J Loosemore <sandra%orion@λcs.utah.edu>
>Subj: bignums are bogus
>I'm not a big bignum user, but I think it might be marginally
>reasonable to support fixed-size 64 bit bignums. I suspect that 64
>bit bignums would take care of a large percentage of uses. This would
>also keep get-universal-time happy for a while to come.
I use bignums for set representations. I think 64 bits is far too
small. I agree that something over a thousand would almost always
suffice.
Don Mitchell
∂16-Apr-87 2137 fateman@mike.Berkeley.EDU Re: Bignums are bogus?
Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 21:37:42 PDT
Received: by ucbvax.Berkeley.EDU (5.57/1.23)
id AA23502; Thu, 16 Apr 87 20:40:18 PST
Received: by mike (3.2/5.17)
id AA14026; Thu, 16 Apr 87 21:38:08 PDT
Date: Thu, 16 Apr 87 21:38:08 PDT
From: fateman@mike.Berkeley.EDU (Richard Fateman)
Message-Id: <8704170438.AA14026@mike>
To: common-lisp@sail.stanford.edu
Subject: Re: Bignums are bogus?
The point about bignums is that you don't have to check for them
overflowing, because they don't. Something more dreadful happens first.
That's why 64bit or 1kbit bignums are no good.
If you want 64 bit numbers or so, I suggest you use floating point.
In fact, a CL-subset with only floating point might be useful,
especially if exact-integer floats were printed like integers.
∂17-Apr-87 0723 DLW@ALDERAAN.SCRC.Symbolics.COM Re: CLARIFICATION: [italics]package arguments.
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Apr 87 07:23:20 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72880; Fri 17-Apr-87 10:22:20 EDT
Date: Fri, 17 Apr 87 10:18 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: CLARIFICATION: [italics]package arguments.
To: diamant%hpfclp@hplabs.HP.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8704162320.AA08469@hpfclp.HP.COM>
Message-ID: <870417101821.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 16 Apr 87 16:20:21 mst
From: John Diamant <diamant%hpfclp@hplabs.HP.COM>
If, as I believe from
my reading of Steele, package names are not allowed, then Symbolics is
violating the standard,
Would you please show us where in CLtL it says that accepting package
names is forbidden, and required to signal an error?
and thus lulling people into writing non-portable
code (as you did). We opted for a strict interpretation, because code
developed on our machines will have a much better chance of being portable.
That's a very different question from "violating the standard".
Supersets of the standard are explicitly allowed; the word "Common" in
the name of "Common Lisp" is derived from the phrase "common subset".
Any implementation can make tradeoffs between providing extended
functionality, or providing only what's required by CLtL and nothing
more, in any area, depending on which criteria are more important in
that case. Or they can provide a "mode" in which extensions are
disabled as much as possible, to help users assure portability of "pure
CL" code. Conformity with the standard only means that an implementing
will correctly run correct CL programs.
∂17-Apr-87 0731 FAHLMAN@C.CS.CMU.EDU time to reactivate cl-cleanup
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 07:31:33 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 10:32:28-EDT
Date: Fri, 17 Apr 1987 10:32 EDT
Message-ID: <FAHLMAN.12295236704.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: time to reactivate cl-cleanup
In-reply-to: Msg of 7 Apr 1987 17:54-EDT from Masinter.pa at Xerox.COM
Larry,
I've finally got a free day to work on some of this stuff. Looking over
my records, it seems I have your summary/current-status messages for the
first seven issues on your list: Adjust-Array-Displacement through
Flet-Implicit-Block. Did you send out the others? If so, please send
me new copies -- I somehow seem to have lost them in my mail-shuffling.
Let me volunteer to take a crack at five of those seven issues for which
I have the material. Defvar-Initialization seems to be in final form,
and I don't feel good about doing Compiler-Warning-Break, since it is
KMP's baby and I think I'm mildly opposed to it. I'll try
Flet-Implicit-Block, Environment-Arguments, Do-Symbols-Duplicates,
Adjust-Array-Displacement (may delegate this one internally), and
Compiler-Warning-Stream. A couple of those are trivial; a couple are
fairly hairy.
If I get the materials in time, and if RPG doesn't indicate that he's
working on it, I'll take a crack at Function-Type; then RPG can make a
final pass over what I've done. Also, I want to produce a new proposal
on &more, just so it will be on the table. (May or may not be able to
get to that one before my trip.)
-- Scott
∂17-Apr-87 0959 RWK@YUKON.SCRC.Symbolics.COM SETF and pathname slots
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 17 Apr 87 09:58:58 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 195190; Fri 17-Apr-87 12:58:53 EDT
Date: Fri, 17 Apr 87 12:58 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: SETF and pathname slots
To: ghenis.pasa@Xerox.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870416-170308-1688@Xerox>
Message-ID: <870417125836.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: 16 Apr 87 17:01 PDT
From: ghenis.pasa@Xerox.COM
Should the standard require SETF to handle pathname slots? If we are
going to have MAKE-PATHNAME, PATHNAME-DEVICE, etc, for consistency we
should also have COPY-PATHNAME and be able to do things like (SETF
(PATHNAME-TYPE old-path) "OLD"). Is there any reason not to?
Careful. Not all systems have pathnames which can be modified.
In our case, it's because we want to preserve EQness of pathnames
with the same components. In other (hypothetical) cases, a pathname
may be an operating-system-related object that you aren't allowed
to directly modify; you request a new one.
The answer is to treat (SETF (PATHNAME-NAME PATH) NEW-NAME)
like (SETF PATH (MAKE-PATHNAME :NAME NEW-NAME :DEFAULTS PATH)).
This is analogous with SETF of LDB.
∂17-Apr-87 1115 diamant%hpfclp@hplabs.HP.COM Re: CLARIFICATION: [italics]package arguments.
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87 11:15:13 PDT
Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Fri, 17 Apr 87 10:15:57 pst
Received: from hpfcjrd.HP.COM by hpfclp.HP.COM; Fri, 17 Apr 87 12:14:56 mst
Received: by hpfcjrd.HP.COM; Fri, 17 Apr 87 11:16:15 mst
Date: Fri, 17 Apr 87 11:16:15 mst
From: John Diamant <diamant%hpfclp@hplabs.HP.COM>
Return-Path: <diamant@hpfcjrd>
Message-Id: <8704171816.AA06364@hpfcjrd.HP.COM>
To: dlw@alderaan.scrc.symbolics.com
Subject: Re: CLARIFICATION: [italics]package arguments.
Cc: common-lisp@sail.stanford.edu
> Would you please show us where in CLtL it says that accepting package
> names is forbidden, and required to signal an error?
"Must" means "must." This means that it "is an error" to do otherwise.
Whether it signals an error or attempts to interpret what the user meant
is at the discretion of the implementation. That means, at the least
that the program was not a correct CL program. However, the second
point applies here (see below).
> Or they can provide a "mode" in which extensions are
> disabled as much as possible, to help users assure portability of "pure
> CL" code. Conformity with the standard only means that an implementing
> will correctly run correct CL programs.
O.K. I stand corrected. It is not a violation of the standard per-say
to provide such an extension. However, to do so without a mode like
what you describe or a flag that provides warning messages when
extensions are used is doing a grave disservice to the user. This is
really the same issue as the list of exported symbols from the LISP
package. Nowhere in CLtL does it say that extra symbols can't be
exported, but you make portable code virtually impossible to write
unless you require that. I believe the same is true for any extension.
It must be clearly delineated either by being in a separate package
(possibly shadowing the symbol in the LISP package) or it must provide
some kind of feedback that the operation just performed is not Common
Lisp. That CLtL does not discuss issues like this is, I think,
extremely unfortunate.
John Diamant
∂17-Apr-87 1122 Masinter.pa@Xerox.COM Re: time to reactivate cl-cleanup
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87 11:22:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 APR 87 11:23:53 PDT
Date: 17 Apr 87 11:28 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: time to reactivate cl-cleanup
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Fri,
17 Apr 87 10:32 EDT
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870417-112353-2553@Xerox>
I was waiting until I got some volunteers for the first seven before
sending out any more.
I'll mail out FUNCTION-TYPE today and the rest soon, but I'd like to
make sure that we get the ones on the table handled.
What do you think about flying &more (whatever it is) by the general
common-lisp mailing list before bringing it to this committee?
∂17-Apr-87 1145 FAHLMAN@C.CS.CMU.EDU time to reactivate cl-cleanup
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 11:45:00 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 14:45:56-EDT
Date: Fri, 17 Apr 1987 14:45 EDT
Message-ID: <FAHLMAN.12295282839.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: time to reactivate cl-cleanup
In-reply-to: Msg of 17 Apr 1987 14:28-EDT from Masinter.pa at Xerox.COM
What do you think about flying &more (whatever it is) by the general
common-lisp mailing list before bringing it to this committee?
Well, I'd like to get the opinions of people I respect on this before
going public. You've seen all this flamage about bignum limit. I
think that Common Lisp is even worse than it used to be as a medium for
rational discussion among informed people, so my inclination is to use
it only as a final sanity check: announce what we propose to do, and
then listen quietly for any really coherent objections, without trying
to answer the lunatics. But that implies that anything we toss out
there ought to be as well-debugged as we can make it in advance.
-- Scott
∂17-Apr-87 1200 Moon@ALDERAAN.SCRC.Symbolics.COM Language extensions (formerly [italics]package arguments.)
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Apr 87 12:00:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 73021; Fri 17-Apr-87 14:59:12 EDT
Date: Fri, 17 Apr 87 14:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Language extensions (formerly [italics]package arguments.)
To: John Diamant <diamant%hpfclp@hplabs.HP.COM>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8704171816.AA06364@hpfcjrd.HP.COM>
Message-ID: <870417145849.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 17 Apr 87 11:16:15 mst
From: John Diamant <diamant%hpfclp@hplabs.HP.COM>
> Or they can provide a "mode" in which extensions are
> disabled as much as possible, to help users assure portability of "pure
> CL" code. Conformity with the standard only means that an implementing
> will correctly run correct CL programs.
O.K. I stand corrected. It is not a violation of the standard per-say
to provide such an extension. However, to do so without a mode like
what you describe or a flag that provides warning messages when
extensions are used is doing a grave disservice to the user. This is
really the same issue as the list of exported symbols from the LISP
package. Nowhere in CLtL does it say that extra symbols can't be
exported, but you make portable code virtually impossible to write
unless you require that. I believe the same is true for any extension.
It must be clearly delineated either by being in a separate package
(possibly shadowing the symbol in the LISP package) or it must provide
some kind of feedback that the operation just performed is not Common
Lisp. That CLtL does not discuss issues like this is, I think,
extremely unfortunate.
It does discuss this, on pages 1 through 3. (It discusses just the
philosophy and doesn't get down to specific cases.) I think that providing
tools to ease writing of portable code is a fine idea, and vendors should
do so. I violently disagree with the idea that any implementation that
does not come with a 100% perfect set of such tools is not Common Lisp.
Note that CLtL pp.1-3 says that Common Lisp is a common dialect to which
each implementation makes any necessary extensions, and that Common Lisp
is designed to make it easy to write programs that depend as little as
possible on machine-specific characteristics, but does not say that
Common Lisp's purpose is to support writing of only programs that are
100% painlessly portable. Common Lisp would be a lot less interesting,
and a lot less widespread, if that were so.
∂17-Apr-87 1329 FAHLMAN@C.CS.CMU.EDU Issue: FLET-IMPLICIT-BLOCK (Revision 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 13:28:15 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 16:29:12-EDT
Date: Fri, 17 Apr 1987 16:29 EDT
Message-ID: <FAHLMAN.12295301642.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FLET-IMPLICIT-BLOCK (Revision 4)
Status: New draft, incorporating results of CL-Cleanup discussion. Two
issues are listed at the end that we must resolve.
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Edit history: Revision 2 by cleanup committee 15-Mar-87 15:13:33
Revision 3 by Masinter (reformatting) 7-Apr-87 17:49:12
Revision 4 by SEF 11-April-87
Description:
Do Flet, Labels, and Macrolet have an implicit block around their bodies
like the body of a Defun? CLtL is silent on this point. Many users
and some implementors assume that such blocks should be established,
since they view these forms as analogous with Defun.
Test case:
(defun test ()
(flet ((test (x) (if x (return-from test 4) 3)))
(list (test nil) (test t))))
(test)
will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would return 4
in an implementation that did not add an implicit block around Flet.
Category: Ommission.
Proposal: FLET-IMPLICIT-BLOCK:YES
Each function created by Flet and Labels and each macro created by
Macrolet has an implicit block around the body. The name of this block
is that same as the (lexical) name of the function or macro.
Current Practice:
Current practice is mixed. Several implementations do not add the
implicit block, others do.
Cost of adopting this change:
Some implementations will have to be modified. This should be a
relatively easy modification.
Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems. Clarifying the issue in any other
way would also require modifications in some implementations.
Cost of converting existing code:
It is possible that some user code would break because it does a return
from within lexical function or macro to an outer block that has the same
name. Such problems will be rare, and the code in question would not
run on all current Common Lisp systems because of the diverse
interpretations currently in effect. It would be possible to detect all
such instances automatically, though it seems unlikely that anyone will
need to use this technique.
Discussion:
The goal is first to clean up an ambiguous situation and, second, to
do this in a way that provides consistent behavior between local and
global definitions.
There are two coherent alternatives to the proposal above:
The first would be to keep the implicit block in Defun, and to clearly
state that the lexical forms do not create implicit blocks. This
violates the goal of consistency between lexical and global definitions,
and it seems to conflict with users' expectations.
The second alternative is to eliminate the implicit block from Defun
rather than adding such blocks to other forms. There is some feeling
that specifying the implicit block in Defun was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself. If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.
On the other hand, eliminating the implicit block in Defun would be a
significant incompatible change. Some users find this implicit block to
be a great convenience for popping out of convoluted code, and some
existing code makes heavy use of this feature. Such code could be
repaired automatically by searching for situations in which the user
returns from a function by name and by adding an appropriate explicit
block to any function containing such a forms, but it would still
require more more work on existing user code than the proposal made
above.
There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common (perhaps even required) in future
Common Lisp implementations. The outcome of these discussions was
general agreement that a compiler could easily eliminate the implicit
block in any case where it is not actually used, and that the impact on
tail-recursion optimization in compiled code is therefore minimal.
Issue: Does the manual say anywhere that Defmacro has such an implicit
block? I couldn't find this. Obviously we must add this if we are
proposing to add an implicit block to Macrolet for reasons of
consistency.
Issue: Do we want to add implicit blocks to Defsetf, Define-Setf-Method,
and Deftype as well? This would provide a certain consistency: any form
that creates a named entity with a user-supplied body would establish a
block.
SEF is inclined to vote yes on both these issues, and on the proposal as
a whole.
∂17-Apr-87 1408 FAHLMAN@C.CS.CMU.EDU Issue: FLET-IMPLICIT-BLOCK (Revision 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 14:08:33 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 17:09:27-EDT
Date: Fri, 17 Apr 1987 17:09 EDT
Message-ID: <FAHLMAN.12295308952.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FLET-IMPLICIT-BLOCK (Revision 5)
Status: New draft, incorporating results of CL-Cleanup discussion.
[ At Masinter's suggestion, this version assumes we agree to add the
blocks to Defmacro, Defsetf, Define-Setf-Method, and Deftype. ]
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Edit history: Revision 2 by cleanup committee 15-Mar-87 15:13:33
Revision 3 by Masinter (reformatting) 7-Apr-87 17:49:12
Revision 4 by SEF 11-Apr-87
Revision 5 by SEF 11-Apr-87
Description:
Do Flet, Labels, Defmacro, Macrolet, Defsetf, Define-Setf-Method, and
Deftype have an implicit block around their bodies like the body of a
Defun? CLtL is silent on this point. Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with Defun.
Test case:
(defun test ()
(flet ((test (x) (if x (return-from test 4) 3)))
(list (test nil) (test t))))
(test)
will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would return 4
in an implementation that did not add an implicit block around Flet.
Category: Ommission.
Proposal: FLET-IMPLICIT-BLOCK:YES
Each function created by Flet and Labels and each macro created by
Defmacro and Macrolet has an implicit block around the body. The name
of this block is that same as the (lexical) name of the function or
macro. Similarly, the body code in Defsetf, Define-Setf-Method, and
Deftype is surrounded by a block with the same name as the accessor
or type.
Current Practice:
Current practice is mixed. Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.
Cost of adopting this change:
Some implementations will have to be modified. This should be a
relatively easy modification.
Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems. Clarifying the issue in any other
way would also require modifications in some implementations.
Cost of converting existing code:
It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block. Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect. It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.
Discussion:
The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions. The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.
There are two coherent alternatives to the proposal above:
The first would be to keep the implicit block in Defun, and to clearly
state that the other forms do not create implicit blocks. This
violates the goal of consistency between lexical and global definitions,
and it seems to conflict with users' expectations.
The second alternative is to eliminate the implicit block from Defun
rather than adding such blocks to other forms. There is some feeling
that specifying the implicit block in Defun was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself. If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.
On the other hand, eliminating the implicit block in Defun would be a
significant incompatible change. Some users find this implicit block to
be a great convenience for popping out of convoluted code, and some
existing code makes heavy use of this feature. Such code could be
repaired automatically by searching for situations in which the user
returns from a function by name and by adding an appropriate explicit
block to any function containing such a forms, but it would still
require more more work on existing user code than the proposal made
above.
There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common (perhaps even required) in future
Common Lisp implementations. The outcome of these discussions was
general agreement that a compiler could easily eliminate the implicit
block in any case where it is not actually used, and that the impact on
tail-recursion optimization in compiled code is therefore minimal.
∂17-Apr-87 1525 Masinter.pa@Xerox.COM Issue: FUNCTION-TYPE (version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87 15:25:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 APR 87 15:26:18 PDT
Date: 17 Apr 87 15:31 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 2)
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870417-152618-2924@Xerox>
Status: General agreement on basic proposal.
Wording to be worked out.
Fahlman volunteer to revise & run by RPG first
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87 15:37:21
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `FUNCTION' is,
therefore, not a reasonable type. The language would be much cleaned up
and improved if functions were treated as a type in a consistent and
useful manner. Most of the reason for the current state of affairs is
the desire for compatibility with the past.
Proposal:
1. Currently the FUNCTION type specifier can only be used for
declaration and not for discrimination. This proposal makes FUNCTION a
full-fledged type. Symbols, whether or not fboundp, and lambda
expressions do not qualify as functions. Specifically the types CONS,
SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are pairwise disjoint.
Under this proposal, a lambda expression is not of type FUNCTION. A list
may not be used to implement any FUNCTION subtype.
Implementations may add sub-types of FUNCTION, for example,
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE etc.
2. This proposal changes the behavior of the FUNCTIONP function such
that it is equivalent to #'(LAMBDA (X) (TYPEP X 'FUNCTION)). In
particular, lists whose cars are LAMBDA, and symbols are no longer
FUNCTIONP.
3. The descriptions of FUNCALL, APPLY, MAPCAR and all functions in CLtL
which take functional arguments are modified to clarify that they will
take either functions, symbols, or lists that represent
lambda-expressions; if given non-functions, they coerce their functional
argument to a function first. Their behavior is not changed.
4. It is an error to use the special form FUNCTION around symbols that
denote macros or special forms. (Some implementations may not signal
this error for performance reasons.) In all non-error situations, the
result of evaluating a FUNCTION special form is required to be of type
FUNCTION.
5. It is an error to invoke SYMBOL-FUNCTION on
Page 76, the description of FUNCTIONP should be amended to read:
``FUNCTIONP is true if its argument is a function (see page 32).''
Page 107, the second sentence should be amended to read:
``*Function* must be a function (see page 32).''
Page 107, the first and fourth examples should be amended to read:
(setq f #'+) (apply f '(1 2)) => 3
(apply #'cons '((+ 2 3) 4)) =>
((+ 2 3) . 4) *not* (5 . 4)
Other examples might require amendment.
Rationale:
I believe that this change takes a currently meaningless concept in
Common
Lisp (a function) and gives it a firmer foundation. Many programmers
cannot rely on FUNCTIONP filtering out true functions from mere symbols.
Current Practice:
Programmers write their own predicate for true FUNCTIONP.
Adoption Cost:
Compiled functions are true functions in almost all implementations,
but,
in some implementations, interpreted functions are represented as lists.
This would need to be changed in the interpreter, FUNCALL, APPLY, and
other places.
Benefits:
A concept would be resurrected: currently the concept of a function in
Common Lisp is bankrupt. Common Lisp would come in closer alignment
with
Scheme. It is the first step towards a Lisp1-ification of Common Lisp.
Conversion Cost:
Unknown. Deep-rooted bugs could be uncovered.
Aesthetics:
Making the concept of a function well-defined will probably be perceived
as a simplification.
Discussion:
The committee felt a need for a new function which replaces the old
behavior of FUNCTIONP, which tests whether the argument is a function
object, a symbol which is FBOUNDP with a function object in its
symbol-function, or a list whose CAR is LAMBDA or some other valid
implementation-specific s-expression representation of a function.
What does COMPILE do? Can one COMPILE already compiled things.
Does (SETF (SYMBOL-FUNCTION x) '(LAMBDA ...)) coerce the lambda
expression?
Is it an error?
SYMBOL-FUNCTION of a special form "is an error".
∂17-Apr-87 1536 Masinter.pa@Xerox.COM Issue FORMAT-ATSIGN-COLON (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87 15:35:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 APR 87 15:36:58 PDT
Date: 17 Apr 87 15:40 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue FORMAT-ATSIGN-COLON (Version 3)
To: cl-cleanup@sail.stanford.edu
Message-ID: <870417-153658-2933@Xerox>
This is the final form of the proposal as distributed at the last X3J13
meeting. No additional work is needed.
Issue: FORMAT-ATSIGN-COLON
References: FORMAT description (p386)
Category: CLARIFICATION
Edit history: Revision 1 by KMP 02/27/87
Revision 2 by cleanup committee 15-Mar-87 14:50:50
Revision 3 by Masinter 15-Mar-87 18:37:23
Problem Description:
CLtL describes the format op syntax as:
"a format directive consists of a tilde (~), optional prefix parameters
separated by commas, optional colon (:) and atsign (@) modifiers, and a
single character indicating what kind of directive this is."
CLtL uses :@ fairly consistently throughout without saying whether @: is
legal. Is @: allowed?
Proposal (FORMAT-ATSIGN-COLON:OK):
There is no required ordering between the @ and : modifier.
Rationale:
This is currently underspecified, and this way of specifying it will
cause the least disruption to user code.
Current practice:
Most implementations accept these in either order. Some implementations
have been known to expect only :@.
Adoption Cost:
The change to accept either syntax is probably quite trivial.
Benefits:
Having @: and :@ mean different things would be awkward.
Conversion Cost:
Existing user code would be unaffected.
Aesthetics:
Leaving these unordered is slightly simpler conceptually.
Discussion:
The cleanup committee supports this clarification.
∂17-Apr-87 1608 vrotney@vaxa.isi.edu Re: CLARIFICATION: [italics]package arguments.
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 16:08:53 PDT
Received: from hpai00 (hpai00.isi.edu) by vaxa.isi.edu (4.12/4.7)
id AA16667; Fri, 17 Apr 87 15:10:06 pst
Received: by hpai00 ; Fri, 17 Apr 87 16:08:56 pdt
From: vrotney@vaxa.isi.edu
Message-Id: <8704172308.AA02892@hpai00>
Date: Fri, 17 Apr 87 15:08:45 PDT
Subject: Re: CLARIFICATION: [italics]package arguments.
To: common-lisp@sail.stanford.edu
In-Reply-To: Your message of 17-Apr-87 10:18:00
X-Mailer: NMail [$Revision: 2.6 $]
In the spirit of making CLTL a slightly better specification, what
about the following extension?
On page 182, extend the statement
"Any argument described as a package name may be either
a string or a symbol."
to
"Any argument described in this section as a package name
or package may be either a string or a symbol."
Bill Vrotney USC/ISI
-------
∂17-Apr-87 1633 Masinter.pa@Xerox.COM Issue IF-BODY (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87 16:32:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 APR 87 16:33:53 PDT
Date: 17 Apr 87 16:38 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue IF-BODY (Version 3)
To: cl-cleanup@sail.stanford.edu
Message-ID: <870417-163353-2990@Xerox>
Status: I (Masinter) tried to merge and summarize the arguments for and
against this proposal. However, I have made enough edits that I no
longer have a lot of confidence that it reflects the "will of the
committee". If you would like to create the next draft, please let me
know.
Issue: IF-BODY
References: IF (p115)
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 02/27/87
Version 2 (IF-BODY:NO) by SEF 3/3/87
Revision 2 by Masinter 17-Apr-87
Problem Description:
IF only allows 2 or 3 arguments. This is restrictive, and not compatible
with current practice in some implementations.
Test Case:
(IF T NIL NIL NIL NIL NIL NIL T).
Currently, this is an error. In some implementations this returns T.
Proposal (IF-BODY:YES):
Extend IF to accept a body of else forms (to be treated as an implicit
PROGN), with syntax (IF test then {else}*).
Rationale:
This is an extension which exists in many implementations.
Current Practice:
Some implementations already provide this feature. Others do not, and
signal an error. A few may provide alternate keyword-driven extensions
to IF that are incompatible with this extension.
Adoption Cost:
Presumably most implementations would require minor adjustments to the
interpreter, the compiler, and any code walking tools. The estimated
cost is low. Implementations which provided an alternate keyword-driven
extension would have more serious difficulties.
Benefits:
This will diminish one common source of aggravation in applications that
took advantage of the extension provided by some implementations, as
they would not have to remove this implementation dependency.
Cost of not adopting this change:
Users with code which had multiple else expressions would have to find
them and convert them to (if test then (PROGN else)) or an equivalent
construct, or else construct a new compatibility package which shadowed
IF. (Implementations which currently provide an extension could continue
to do so, although programs that used it would not be valid Common
Lisp.)
Conversion Cost:
Most code which simply uses IF would not be affected adversely except in
implementations which provided keyword-driven extensions.
Some user-defined code might depend on understanding the syntax of IF
because it is defined to be a primitive special form. Such programs
would require modification, although those modifications are likely to
be simple.
Aesthetics:
Some people like the IF body idea and find it more visually aesthetic
than the more-parenthesized (and incidentally also more-indented) COND
alternative.
Some people really dislike the idea of an IF body: it would destroy the
symmetry of the THEN and ELSE clauses in an IF expression, and would
lead to a visually confusing format.
This proposal leaves that choice to the individual programmer.
Discussion:
Much of the discussion around this proposal centered on the form of the
arguments rather than on the proposal itself. The issue of whether the
fact that some implementations had chosen to extend IF should influence
the future of Common Lisp was debated.
Pitman: "this is a source of frustration for users, only a small
fraction of
which care about arguing about whether more than three arguments is
aesthetic.
They just want their programs to port without hassle. CLtL has egged
on the
problem by explicitly suggesting that such extensions were
permissible."
Fahlman: "Whatever we decide about the merits of this proposal itself, I
want to
VEHEMENTLY OBJECT to the rationale put forward in this proposal....
it
is an extremely bad precedent . . .
This same argument could be used to slip any number of unspeakable
horrors into the language...."
Moon: "the mere fact that some people like this extension is not
sufficient reason to put it into the language, but it is certainly
sufficient reason to -discuss- putting it into the language."
Steele: " I agree with Scott's assessment of the IF-BODY proposal
(though I think
the proposal was worth making). I would point out that one of the
reasons for including IF in the language is to have a simple primitive
that can easily be recognized, by people and by program-walkers alike,
as being the simplest conditional and not having implicit PROGNs as do
WHEN, UNLESS, and COND."
Summary: Most of the cleanup committee are mildly opposed to adopting
this proposal. We agree that we should consider, but not be held hostage
to, extensions made by some implementations and demanded by their users.
∂17-Apr-87 1634 Masinter.pa@Xerox.COM status.report
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87 16:33:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 APR 87 16:34:50 PDT
Date: 17 Apr 87 16:39 PDT
From: Masinter.pa@Xerox.COM
Subject: status.report
to: cl-cleanup@sail.stanford.edu
Message-ID: <870417-163450-2991@Xerox>
Status of proposals before CL-CLEANUP committee
Date: 17-Apr-87
ADJUST-ARRAY-DISPLACEMENT (revision 1)
Received but not discussed.
Need volunteer to lead discussion, summarize positions.
remailed 7-apr-87
SEF volunteered to delegate.
COMPILER-WARNING-BREAK (revision 2)
not Released.
Questions on interaction with condition proposal.
Defer to error/signal/condition committee?
remailed 7-apr-87
SEF suggested KMP should work on.
COMPILER-WARNING-STREAM (Revision 3)
Released
Comment from Dussand at TI, forwarded to cl-cleanup, no response.
remailed 7-apr-87
SEF volunteered to work on.
DEFVAR-INITIALIZATION (Revision 3)
Released
remailed 7-apr-87
(final form)
DO-SYMBOLS-DUPLICATES (Revision 1)
Received but not discussed
Need volunteer to put in standard format
mailed 7-apr-87
SEF volunteered to work on
ENVIRONMENT-ARGUMENTS (revision 1)
Need volunteer to work over the proposal further.
Mailed 7-apr-87
SEF volunteered to work on
FLET-IMPLICIT-BLOCK (Revision 5)
Discussion & agreement on cl-cleanup.
revision by Fahlman, 17-Apr-87 to cl-cleanup
FORMAT-ATSIGN-COLON (Revision 3)
Released.
(final form, mailed 17-Apr-87)
FORMAT-OP-C (revision 1)
Discussed and agreed, final form not yet available
(with Moon's amendment)
Need volunteer.
FUNCTION-TYPE (revision 2)
General agreement on basic proposal.
Wording to be worked out.
Mailed 17-Apr-87
Fahlman volunteered to revise & run by RPG
IF-BODY (Version 3)
General agreement to recommend against.
Final form not yet available.
Version 3 mailed by Masinter , 17-Apr-87
IGNORE-ERRORS
Discussed and agreed, final form not yet available
(LMM: Some objections, defer to error/signal committee?)
Need volunteer.
IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
Released
Should remove confusing "To further clarify: " which is
about INTERN and not IMPORT.
PEEK-CHAR-READ-CHAR-ECHO
Agreed to be controversial
Need volunteer to summarize positions.
PRINC-CHARACTER:WRITE-CHAR
Discussed and agreed, final form not yet available
(write-char choice)
Need volunteer.
PROMPT-FOR
Agreed to be controversial
Need volunteer to summarize positions.
REMF-DESTURCTION-UNSPECIFIED
Not discussed
Need volunteer to check over, lead discussion.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
(Should FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Tabled, a subset which deals with only those functions that
don't work in positions will be separated out.
Need volunteer.
SHARPSIGN-BACKSLASH-BITS
No general agreement (the meeting notes read "we cringed")
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-PACKAGE
Discussed, without general agremenet.
Need volunteer to summarize positions.
TAILP-NIL
Received but not discussed
Need volunteer to lead discussion, summarize positions.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Discussed and agreed, final form not yet available
(choice 1c & 2c)
Need volunteer.
∂17-Apr-87 1737 FAHLMAN@C.CS.CMU.EDU Issue: COMPILER-WARNING-STREAM (Revision 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 17:37:14 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 20:38:15-EDT
Date: Fri, 17 Apr 1987 20:38 EDT
Message-ID: <FAHLMAN.12295346987.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: COMPILER-WARNING-STREAM (Revision 4)
Status: Released. This version slightly revised to incorporate Dussud's
comment about the effect of this change on Dribble and to clean up some
awkward wording.
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
Revision 2 at committee meeting 15-Mar-87 14:18:56
Revision 3 reformat by Masinter 15-Mar-87 17:42:10
Revision 4, minor revision by SEF 15-Apr-87
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be specified what stream such warnings are printed on.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.
As a corollary of this, DRIBBLE is required to record from
*ERROR-OUTPUT* as well as *STANDARD-INPUT* and *STANDARD-OUTPUT* so that
it can record any compiler warnings that may be generated while it is in
effect.
Rationale:
Compiler warning output is a widely accepted feature of compilation.
Warnings that come via the WARN function will go to the stream that is
the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is expected
to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear what stream receives the warnings.
Conversion Cost:
Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.
The cleanup committee supports this change.
∂17-Apr-87 2007 FAHLMAN@C.CS.CMU.EDU Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 20:07:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 17 Apr 87 23:08:34-EDT
Date: Fri, 17 Apr 1987 23:08 EDT
Message-ID: <FAHLMAN.12295374347.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
Status: New Proposal (in the CL-Cleanup process, anyway)
Issue: DO-SYMBOLS-DUPLICATES
References: Do-Symbols, Page 187
Category: Clarification
Edit history: Revision 1 by SEF 17-Apr-87
Problem Description:
CLtL specifies that Do-Symbols executes the body once for each symbol
accessible in the package. It does not say whether it is permissible
for the body to be executed more than once for some accessible symbols.
The term "accessible" is defined on page 172 to include symbols
inherited from other packages (not including any symbols that may be
shadowed). It is very expensive in some implementations to eliminate
duplications that occur because the same symbol is inherited from
multiple packages.
Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED
Add to the specification of DO-SYMBOLS a note that it may execute the
body more than once for some symbols.
Rationale:
Most uses of DO-PACKAGE would not be harmed by the presence of
duplicates. For these applications it is unreasonable to force users to
pay the high cost of filtering out the duplications. Users who really
want the duplicates to be removed can add additional code to do this job.
Current Practice:
Many implementations have always produced duplicate values.
Adoption Cost:
None. Implemenations would still be free to eliminate the duplications,
though code will not be assuming that this has been done.
Benefits:
Clarification of a situation that is currently ambiguous.
Conversion Cost:
Users who have been assuming that DO-SYMBOLS eliminates duplications
will have to be modified, but such code would run on few existing Common
Lisp systems.
Aesthetics:
It would be cleaner to present each symbol exactly once. This is a
clear case of choosing efficiency over elegance.
Discussion:
This issue was discussed on the Common Lisp mailing list in 1985, and
the solution proposed here seems to have been informally agreed to at
the time -- there was no formal decision-making process in place then.
∂17-Apr-87 2109 vrotney@vaxa.isi.edu Sec.11.7 [italics]package arguments.
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 21:09:03 PDT
Received: from hpai00 (hpai00.isi.edu) by vaxa.isi.edu (4.12/4.7)
id AA18659; Fri, 17 Apr 87 20:10:16 pst
Received: by hpai00 ; Fri, 17 Apr 87 21:09:05 pdt
From: vrotney@vaxa.isi.edu
Message-Id: <8704180409.AA02941@hpai00>
Date: Fri, 17 Apr 87 20:08:53 PDT
Subject: Sec.11.7 [italics]package arguments.
To: common-lisp@sail.stanford.edu
X-Mailer: NMail [$Revision: 2.6 $]
In the spirit of making CLTL a slightly better specification, what
about the following extension?
On page 182, extend the statement
"Any argument described as a package name may be either
a string or a symbol."
to
"Any argument described in this section as a package name
or package may be either a string or a symbol."
--------------------------------------------------------------------------------
Post Script:
After sending the above message I realized that someone may interpret
it too literally. My original message on this indicated that the
functions in Sec.11.7 created a "misinterpretation portability trap"
or what ever you want to call it. The above is a suggestion for an
extension that means that all arguments in this section named
[italics]package, be allowed to be a string or symbol, as they can be
in some implementations. I suppose the extended sentence above could
be worded better to help define what something described as a "package
name" means. For example,
"Any argument described in this section as a package name
may be either a string or symbol. Any argument designated
as [italics]package may be a package, string or symbol."
In other words, reqardless of what most of us think CLTL says these
package arguments can or can not be, a good future extension might be
to specify exactly that all of these package arguments (except for a
few) be allowed to be a package, string or symbol.
Bill Vrotney USC/ISI
-------
∂17-Apr-87 2121 edsel!bhopal!jonl@navajo.stanford.edu CLARIFICATION: [italics]package arguments.
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 21:21:09 PDT
Received: by navajo.stanford.edu; Fri, 17 Apr 87 20:20:45 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA01217; Fri, 17 Apr 87 20:18:48 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA00738; Fri, 17 Apr 87 21:16:27 PDT
Date: Fri, 17 Apr 87 21:16:27 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704180416.AA00738@bhopal.edsel.com>
To: navajo!vrotney%vaxa.isi.edu@navajo.stanford.edu
Cc: navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: navajo!vrotney@vaxa.isi.edu's message of Fri, 17 Apr 87 15:08:45 PDT
Subject: CLARIFICATION: [italics]package arguments.
Somewhere between 1 year ago and 2 years ago, I sent out a proposal to this
list suggesting that the package functions of CLtL section 11.7 fall into
four categories:
(1) those whose argument is documented as "must be a package";
(2) those whose argument is documented as "a package";
(3) those whose argument is documented as a "name" of (or for) a package;
(4) all the rest.
Contrary to what John Diamant suggested, I think that very few functions
fall into category (1). The vast majority seem to be in category (2).
Both Symbolics and Lucid apparently, independently, made a decision to
interpret the documentation of category (2) to mean that any argument
reasonably coercible to a package would in fact be so coerced. That is,
if the documentation goes out of its way to say "must be a package" for
some functions, but doesn't do so for others, then it must be that the
latter ones can be more generous in accepting alternate forms.
This implies, for example, that a string or symbol could be supplied as
the "pacakge" argument to UNINTERN; but the argument to PACKAGE-NICKNAMES
can only be of type package, because it "must be a packge".
There wasn't a lot of discussion back then about these points -- certainly
there was no serious objection to them. Probably the HP folks weren't
receiving the mail then?
-- JonL --
∂17-Apr-87 2229 MURRAY%cs.umass.edu@RELAY.CS.NET OR and Multiple Values
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 17 Apr 87 22:29:12 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ai22053; 18 Apr 87 1:22 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ce03359; 18 Apr 87 1:17 AST
Date: Fri, 17 Apr 87 18:27 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SAIL.STANFORD.EDU
Subject: OR and Multiple Values
X-VMS-To: CLMAIL
> Is it reasonable to expect SOME to return multiple values?
> What if the predicate returns multiple values?
>>No, for the same reason that OR returns only a single value for clauses
>>other than the last one. That is, the implicit NULL test "consumes" the
>>values returned from the predicate, discarding all but the last one.
I've always been a little disturbed by this fact. I suppose the
extra effort to always insure multiple values are dealt with "properly"
is probably not worth it in general. However, I'll take this opportuntiy
to again ask for a MULTIPLE-VALUE-OR special form, since it cannot be
defined without consing in Common-Lisp (I guess it COULD be a macro that
expands into consing code, but the compiler would know about, but that is
another discussion).
- Kelly
∂17-Apr-87 2236 MURRAY%cs.umass.edu@RELAY.CS.NET Fixnums Bogus
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 17 Apr 87 22:36:24 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa22296; 18 Apr 87 1:33 EDT
Received: from cs.umass.edu by RELAY.CS.NET id cj03359; 18 Apr 87 1:28 AST
Date: Fri, 17 Apr 87 19:51 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SAIL.STANFORD.EDU
Subject: Fixnums Bogus
X-VMS-To: CLMAIL
Just to throw my two cents in...
It is undeniably a loophole that bignums don't have some
minimum size, because fixnums don't have a minimum size,
and thus one could "legally" get away with integers that
only need to be big enough to hold other "defined"
minimum values, such as ARRAY-DIMENSION-LIMIT,
which must be greater than 1024.
My question is: does anybody really use these constants
to conditionalize their programs? It seems to me, either
an implementation will run your program, or not.
Without official validation, a system calling itself a
"Common Lisp" can only be refering to its "spirit",
(-: which likes to float around in a large virtual memory
with many friends who speak microcode :-)
Kelly
∂18-Apr-87 0049 Mailer@XX.LCS.MIT.EDU OR and Multiple Values
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Apr 87 00:49:06 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 18 Apr 87 03:51-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 38683; 18 Apr 87 03:49:17-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 33358; 18 Apr 87 03:45:01-EDT
Date: Sat, 18 Apr 87 03:43 EDT
From: Don Morrison <dfm@JASPER.PALLADIAN.COM>
Subject: OR and Multiple Values
To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 17 Apr 87 18:27 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET
Message-ID: <870418034319.5.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>
Date: Fri, 17 Apr 87 18:27 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
However, I'll take this opportuntiy to again ask for a MULTIPLE-VALUE-OR special
form, since it cannot be defined without consing in Common-Lisp (I guess it COULD
be a macro that expands into consing code, but the compiler would know about, but
that is another discussion).
What are the semantics of MULTIPLE-VALUE-OR? Does it
a) return all the values returned by the first form with a non-null first value
(since we're no longer implicitly expecting exactly one value what does it
do in the case of zero values?)
b) return all the values returned by the first form with all its values non-null
(if there are zero values does that count as all non-null?)
c) return all the values returned by the first form with any of its values non-null
(if there are zero values does that count as none non-null?)
d) return the maximum number of values returned by any forms with each slot chosen
from the first form that returned non-null in that form (this one would require
always evaluating all the forms, so I'm probably getting bogus here)
e) return all the values returned by the first form that returned the maximum number
of non-null values (even more bogus)
f) ...
I think more to the heart of the matter is that Common LISP needs a way to grab,
inspect, and pass on an unknown number of multiple values without consing (and yes,
avoiding consing can be crucial for real applications give the current state of the
art for garbage collection on conventional hardware). It's possible that, using
multiple-value-call, simply having some way of doing non-consing &rest arguments may
be sufficient. For example, I believe the following gives something close to the
semantics of (a) without consing, if the bogus declaration ensures that the &rest
argument isn't consed (and, of course, if the implementors haven't introduced
gratuitous consing, which is far from a sure thing, especially in
multiple-value-call....).
(defmacro multiple-value-or (&rest forms) ; don't care about this &rest
`(block #0=#:mv-or-block
,@(mapcar
#'(lambda (form)
`(multiple-value-call
#'(lambda (&rest #1=#:mv-or-args) ; this &rest musn't cons
(declare (dynamic-extent #1#))
(when (first #1#)
(return-from #0# (apply #'values #1#))))
,form))
forms)
nil))
For example,
(multiple-value-or (mumble) (shout) (bellow))
->
(block #:mv-or-block
(multiple-value-call
#'(lambda (&rest #:mv-or-args)
(declare (dynamic-extent #:mv-or-args))
(when (first #:mv-or-args)
(return-from #:mv-or-block (apply #'values #:mv-or-args))))
(mumble))
(multiple-value-call
#'(lambda (&rest #:mv-or-args)
(declare (dynamic-extent #:mv-or-args))
(when (first #:mv-or-args)
(return-from #:mv-or-block (apply #'values #:mv-or-args))))
(shout))
(multiple-value-call
#'(lambda (&rest #:mv-or-args)
(declare (dynamic-extent #:mv-or-args))
(when (first #:mv-or-args)
(return-from #:mv-or-block (apply #'values #:mv-or-args))))
(bellow))
nil)
(B) and (c) can be implemented by replacing "(when (first #1#)" by
"(when (every #'identity #1#)" and "(when (some #'identity #1#)",
respectively.
∂18-Apr-87 0538 RPG Packages
To: common-lisp@SAIL.STANFORD.EDU
On the proposal:
"Any argument described in this section as a package name
or package may be either a string or a symbol."
This, of course, makes the language just a little worse than it is.
There is no rational sense in which a string or a symbol is a
package.
-rpg-
∂18-Apr-87 1251 REM@IMSSS OR if some argument returns no values
Received: from IMSSS by SAIL with PUP; 18-Apr-87 12:50 PDT
Date: 18 Apr 1987 1159-PDT
From: Rem@IMSSS
Subject: OR if some argument returns no values
To: Common-LISP@SU-AI
The manual doesn't say as far as I can tell what OR is supposed to do
if one of the arguments doesn't return any values at all. OR is defined
in terms of COND, which likewise isn't documented in the no-return-value
case. If CL doesn't support no-return-values at all within the general
framework of multiple return values, then this question is moot.
(Can an expert say whether no-return-values is as legal as one-return-value
or multiple-return-values?) If CL *does* support no-return-values, or if
that is a legitimate extension to the language, then my opinion is that
it should "be an error" to do an OR (or COND) with one of the tests
not returning any value at all, the logic being "if the function won't tell
me what its answer is, how am I supposed to use that answer to make a
decision?". AND and a few other functionoids may fall into this same
category as OR and COND.
-------
∂18-Apr-87 1407 diamant%hpfclp@hplabs.HP.COM Re: CLARIFICATION: [italics]package arguments.
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 18 Apr 87 14:06:58 PDT
Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Sat, 18 Apr 87 10:52:47 pst
Received: by hpfclp.HP.COM; Sat, 18 Apr 87 12:51:52 mst
Date: Sat, 18 Apr 87 12:51:52 mst
From: John Diamant <diamant%hpfclp@hplabs.HP.COM>
Return-Path: <diamant@hpfclp>
Message-Id: <8704181951.AA22390@hpfclp.HP.COM>
To: edsel!bhopal!jonl@navajo.stanford.edu
Subject: Re: CLARIFICATION: [italics]package arguments.
Cc: common-lisp@sail.stanford.edu
> Contrary to what John Diamant suggested, I think that very few functions
> fall into category (1). The vast majority seem to be in category (2).
After looking through several pages of CLtL, I see that you are right that
only a few fall in category (1). However, it is still a major leap to
conclude (2) simply because the "must" is not listed for the function. If
that were the intended interpretation, then a statement at the beginning
of the section should say that. This is comparable to taking a word and
saying in this sentence it means "A" and in this other sentence it means "B."
It is still true that package means package, and not package name, so what
you are talking about is still an extension, not something that can be
concluded from the text.
> There wasn't a lot of discussion back then about these points -- certainly
> there was no serious objection to them. Probably the HP folks weren't
> receiving the mail then?
Well, that's probably true. I certainly wasn't, as I wasn't with HP 2
years ago. Even if the mailing list was being received, it could have been
missed. However, when interpretations like that are "added" to CLtL, we
need to be careful to record them for inclusion in further standards.
Standards don't do us any good if people decide to reinterpret them beyond
what is stated, simply because they don't like the standard.
Note that I have no objection to your proposed enhancement, but it requires
a clarification to the standard, not just a joint decision from some of
the implementors.
Regarding David Moon's comments: we will have to agree to disagree. I believe
that any extension to CLtL should be clearly delineated or not included.
I would be much happier if CLtL stated how this delineation must occur
(explicitly requiring extensions to not be in the LISP package, possibly
shadowing symbols that are, for instance). Portability is probably the
most important feature of Common Lisp, and I hate to see such a lack of
committment to it that if something isn't convenient because of portability
issues, we just ignore the portability issue.
John Diamant
∂18-Apr-87 1444 FAHLMAN@C.CS.CMU.EDU OR if some argument returns no values
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Apr 87 14:44:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 18 Apr 87 17:44:56-EDT
Date: Sat, 18 Apr 1987 17:44 EDT
Message-ID: <FAHLMAN.12295577578.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: OR if some argument returns no values
To Rem at IMSSS:
The manual doesn't say as far as I can tell what OR is supposed to do
if one of the arguments doesn't return any values at all.
Page 133-134:
"If the caller of a function does not request multiple values, but the
called function returns multiple values, then the first value is given
to the caller and all the other values are discarded; if the called
function produces zero values, then the caller gets NIL as a value."
OR, COND, and friends do not expect multiple values from the sub-forms,
except in certain tail-recursive poisitions.
Seems pretty clear to me. Whether you like this behavior is another
question.
-- Scott
∂18-Apr-87 1628 Randy%acorn%LIVE-OAK.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: SETF and pathname slots
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Apr 87 16:27:56 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 18 Apr 87 19:30-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 38740; 18 Apr 87 19:29:54-EDT
Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 65237; Sat 18-Apr-87 19:17:01-EST
Date: Fri, 17 Apr 87 10:39 EDT
From: Randy%acorn@oak.lcs.mit.edu
To: ghenis.pasa@Xerox.COM
Subject: Re: SETF and pathname slots
Cc: common-lisp@sail.stanford.edu
Date: 16 Apr 87 17:01 PDT
From: ghenis.pasa@Xerox.COM
Should the standard require SETF to handle pathname slots? If we are
going to have MAKE-PATHNAME, PATHNAME-DEVICE, etc, for consistency we
should also have COPY-PATHNAME and be able to do things like (SETF
(PATHNAME-TYPE old-path) "OLD"). Is there any reason not to?
Probably not, since a lot of implementations might want to cache
pathnames (so they are EQ). You could have COPY-PATHNAME take
keyword arguments of slots to change in the copying process.
Or you could probably use MERGE-PATHNAMES for these sorts of
things.
Random
∂18-Apr-87 1922 FAHLMAN@C.CS.CMU.EDU Environment-Arguments
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Apr 87 19:22:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 18 Apr 87 22:23:05-EDT
Date: Sat, 18 Apr 1987 22:23 EDT
Message-ID: <FAHLMAN.12295628211.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Environment-Arguments
Before I try to put the Environment-Arguments proposal into final form,
there's an unresolved issue we need to clean up.
In mail several months ago, Moon said that he agreed with adding an
optional environment argument to MACRO-FUNCTION, but that for
consistency we should also add such an argument to SPECIAL-FORM-P,
SYMBOL-FUNCTION, and SYMBOL-VALUE.
I think that this is wrong. (Masinter apparently does too, but I'll
speak for myself.)
This facility isn't designed for writing debuggers; it is meant to allow
macro-expanding macros to operate properly. Macros sometimes need to
expand other macros at compile time so that they can do SETF-like
things. In accessing some otehr macro's definition, a macro should take
cognizance of any MACROLET definitions and of lexical function
definitions that might shadow a macro definition. Therefore, they need
to be able to call MACRO-FUNCTION with an environment arg.
I don't think macros need to get at function definitions and values in
the same way. Function definitions do not have to be available at
compile time, nor do values. And special forms are immutable: they
cannot be redefined, so presumably they cannot be shadowed either.
(Larry proposes to make this explicit as part of this proposal; I would
prefer to make it a separate proposal, but agree with the
clarification.)
So I don't believe that SPECIAL-FORM-P, SYMBOL-FUNCTION, or SYMBOL-VALUE
need an environment arg after all.
Dave, do you buy that analysis? If so, I'll propoduce a proposal along
the lines of what Larry sent out.
-- Scott
∂18-Apr-87 2215 MURRAY%cs.umass.edu@RELAY.CS.NET MULTIPLE-VALUE-OR, and Consing
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Apr 87 22:15:17 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac00469; 19 Apr 87 1:08 EDT
Received: from cs.umass.edu by RELAY.CS.NET id am08685; 19 Apr 87 1:03 AST
Date: Sat, 18 Apr 87 19:34 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SAIL.STANFORD.EDU
Subject: MULTIPLE-VALUE-OR, and Consing
X-VMS-To: CLMAIL
>From: Don Morrison <dfm@jasper.palladian.com>
>What are the semantics of MULTIPLE-VALUE-OR? ...
It should be the same as OR, but return multiple-values. Since OR only
conditionalizes on the first value, MULTIPLE-VALUE-OR does the same,
but returns all the rest of the values as well.
As standard with multiple-values, when less than asked for are returned,
the extra are filled out with NIL's, so no-values is the same as a NIL value.
>I think more to the heart of the matter is that Common LISP needs a way to grab,
>inspect, and pass on an unknown number of multiple values without consing
> (and yes, avoiding consing can be crucial for real applications
> give the current state of the art for garbage collection
> on conventional hardware). It's possible that, using
>multiple-value-call, simply having some way of
>doing non-consing &rest arguments may be sufficient. ...
I whole-heartly agree that A) Unneccessary consing should always be avoided,
B) it would be great to have &rest args that don't cons.
I currently have plans to have a STACK-LIST declaration that declares that
a &Rest is stack-allocated (as well as WITH-STACK-LIST, ala Lisp Machines)
in my system. I would suggest that others consider this as well, but
of course, it is only a declaration that could be ignored.
(I already avoid consing for (&Rest ignore), which should be easy).
My point is that MULTIPLE-VALUE-OR can only be done efficiently by low-level
implementation-specific code, and thats why it should be in Common Lisp.
- Kelly Edward Murray
University of Massachusetts, Amherst
∂19-Apr-87 1029 primerd!doug@enx.prime.pdn Bigosities
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87 10:29:50 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA13976@EDDIE.MIT.EDU>; Sun, 19 Apr 87 13:31:55 EDT
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA14369; Sun, 19 Apr 87 13:10:47 EST
Message-Id: <8704191810.AA14369@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 17 Apr 87 10:20:06 EST
Subject: Bigosities
To: common-lisp@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 17 Apr 87 10:20:06 EST
The concept that 64 bits could be construed as a reasonable integer
limit is silly since there are many hardware architectures where a
basic arithmetic operation can be done on 64 bits in both integer
and floating point. Also 64 bits is only ~21 decimal digits.
Doug
∂19-Apr-87 1726 sandra%orion@cs.utah.edu Re: Bigosities
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87 17:26:52 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA14758; Sun, 19 Apr 87 18:29:35 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA03009; Sun, 19 Apr 87 18:29:31 MDT
Date: Sun, 19 Apr 87 18:29:31 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8704200029.AA03009@utah-orion.ARPA>
Subject: Re: Bigosities
Newsgroups: fa.common-lisp
To: common-lisp@sail.stanford.edu
References: <8704191810.AA14369@primerd.prime.com>
In article <8704191810.AA14369@primerd.prime.com>,
primerd!DOUG@ENX.Prime.PDN writes:
> The concept that 64 bits could be construed as a reasonable integer
> limit is silly since there are many hardware architectures where a
> basic arithmetic operation can be done on 64 bits in both integer
> and floating point. Also 64 bits is only ~21 decimal digits.
>
> Doug
Maybe I should have put a few :-)'s in my original posting: I certainly
wasn't intending 64-bit bignums as a serious proposal. My reason for
throwing out the idea in the first place was to point out that integer
overflow is bad news whether the limit on integer size is large or small,
and also to point out that the manual doesn't *say* it has to be huge.
If the limit is huge, we can maybe get away with some handwaving and saying
that any program that runs up against the limit is wedged anyway. But
that does not change the fact that there is a problem with overflow.
-Sandra
∂19-Apr-87 1802 FAHLMAN@C.CS.CMU.EDU Issue ADJUST-ARRAY-DISPLACEMENT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87 18:02:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 19 Apr 87 21:03:10-EDT
Date: Sun, 19 Apr 1987 21:03 EDT
Message-ID: <FAHLMAN.12295875812.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
[Note: some comments by Nick Gall on DISPLACED-ARRAY-P, a totally
separate proposal on Steele's list, were mixed in with the discussion
file Larry sent out, probably because Gall addressed several distinct
issues in the same message.]
Status: New proposal (discussed earlier on Common Lisp list).
Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: Steele p.297
Category: Clarification
Edit history: Revision 1 by SEF, 18-Apr-87 (from Steele's list)
Problem Description:
The interaction of Adjust-Array and displacement is insufficiently
specified in the case where the array being adjusted is displaced.
Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
Suppose we are adjusting array A, which is perhaps displaced
to B before the Adjust-Array call and perhaps to C after the call.
(1) A is not displaced before or after: The dimensions of A are altered,
and the contents rearranged as appropriate. Additional elements of A
are taken from the :initial-element. The use of :initial-contents
causes all old contents to be discarded.
(2) A is not displaced before, but is displaced to C after. As
specified in CLtL, none of the original contents of A appears in A
afterwards; A now contains the contents of C, without any rearrangement
of C.
(3) A is displaced to B before the call, and is displaced to C after the
call. As in case (2), the contents of B do not appear in A afterward
(unless such contents also happen to be in C). If
:displaced-index-offset is not specified in the Adjust-Array call, it
defaults to zero; the old offset (into B) is not retained.
(4) A is displaced to B before the call, but not displaced afterward. A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :initial-element. However, the use of
:initial-contents causes all old contents to be discarded.
Note that if array X is displaced to array Y, and array Y is displaced
to array Z, and array Y is altered by Adjust-Array, array X must now
refer to the adjusted contents of Y. This means that an implementation
may not collapse the chain to make X refer to Z directly and forget that
the chain of reference passes through array Y. (Cacheing techniques are
of course permitted, as long as they preserve the semantics specified
here and in CLtL.)
If X is displaced to Y, it is an error to adjust Y in such a way that it
no longer has enough elements to satisfy X. This error may be signalled
at the time of the adjustment, but this is not required.
Rationale:
This interaction must be clarified. This set of rules was proposed some
time ago, as a result of discussions on the Common Lisp mailing list,
and this model has been adopted by many Common Lisp implementations.
Current Practice:
Many implementations currently follow the model proposed here. Others
may do something random. There is no major competing alternative.
Adoption cost:
Some existing implementations may have to be changed, but adopting any
other model would be worse. Public-domain code implementing this model
is available from CMU.
Benefits:
Clarification of a situation that is currently not addressed by the
standard.
Conversion Cost:
This is a relatively uncommon situation, which is the reason it didn't
occur to the original language designers to specify how it works. Any
user code that cares about this issue probably already follows the
proposed model.
Discussion:
Discussed long ago on the Common Lisp mailing list. This proposal
attempts to capture the overall consensus that emerged at that time.
∂19-Apr-87 2028 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue IF-BODY (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Apr 87 20:27:48 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 119725; Sun 19-Apr-87 23:27:59 EDT
Date: Sun, 19 Apr 87 23:27 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue IF-BODY (Version 4)
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
References: <870417-163353-2990@Xerox>
Message-ID: <870419232729.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Notes on this draft:
I expanded a few of the sections where I thought important information
was missing.
I changed the Test Case to one which would show up a case that
the old test case hadn't -- some implementations quietly ignore
the additional forms.
I removed the Summary, which I thought sounded downright paranoid.
The whole point of committees and voting is to ensure due process.
It goes without saying that we're not held hostage by much of
anything. Words like "hostage" suggest an undue air of tension.
I added another clump of discussion by me in the Discussion.
==============================================================================
Issue: IF-BODY
References: IF (p115)
Category: ENHANCEMENT
Edit history: 27-Feb-87, Version 1 by Pitman
3-Mar-87, Version 2 by Fahlman (added IF-BODY:NO)
17-Apr-87, Version 3 by Masinter (misc editing)
19-Apr-87, Version 4 by Pitman (misc editing)
Status: Not for release
Problem Description:
CLtL defines the meaning of an IF expression only in the case of
2 or 3 arguments. Some implementations extend the meaning to allow
more arguments, but this extension tends to thwart code portability
because of widespread use of IF.
Test Case:
(IF NIL 'THEN 'ELSE 'MORE)
According to CLtL, this is an error.
In some implementations, this returns ELSE.
In some implementations, this returns MORE.
In some implementations, this signals an error at syntax analysis time.
Proposal (IF-BODY:YES):
Extend IF to accept a body of else forms (to be treated as an implicit
PROGN), with syntax (IF test then {else}*).
Rationale:
Some implementations provide this extension while others do not.
Dependence of user code on this feature commonly goes undetected
until the code is ported to a system which does not have the feature,
which is often inconveniently late in the development cycle.
In principle, it is possible to develop and test code thoroughly
in one (extended) dialect, compile it in another dialect without
obtaining any compiler warnings, and then to run it in the second
dialect and find that it does not behave as the original programmer
intended. This phenomenon is counter to the portability goals of
Common Lisp.
Current Practice:
Some implementations already provide this feature.
A few implementations provide alternate keyword-driven extensions
that are incompatible with this extension.
Some implementations signal an error if other than two or three
arguments are passed.
Some implementations quietly ignore additional arguments to IF, making
it hard to detect errors in code that was developed on systems with
the extended syntax.
Adoption Cost:
Presumably most implementations would require minor adjustments
to the interpreter, the compiler, and any code walking tools.
The estimated cost is low.
Implementations which provided an alternate keyword-driven
extension could have more serious difficulties. In some cases,
however, heuristic solutions which select a semantics based on
the presence or absence of keywords may be of use.
Benefits:
This will diminish one common source of aggravation in applications
that took advantage of the extension provided by some implementations,
as they would not have to remove this implementation dependency.
Cost of not adopting this change:
Unless someone proposes an ammendment to CLtL which requires that
LISP:IF not be extended to allow additional arguments, users will
continue to develop code in some implementations where these features
are available, and then upon porting their code may notice that their
code either does not compile (generates syntax errors) or does not
compile correctly (the additional forms are quietly ignored and the
code generated is not what the writer intended).
If this proposal is not adopted, Common Lisp users doing ports from
certain dialects to certain other dialects will repeatedly risk lost
time and effort in debugging problems which could be defined away
by this proposal.
Users with code which had multiple else expressions should find them
and convert them to (COND (test then) (T {else}*)), but in practice
they may be very hard to find until the time the port is done, which
is usually inconveniently late in the development cycle for this kind
of bug to be detected.
Conversion Cost:
Uses of the IF special form in portable user-defined code would
not be affected since the extension is ``upward compatible.''
Some portable user-defined code (such as macros or code-walking
utilities) might depend on understanding the syntax of IF because
it is defined to be a primitive special form. Such programs would
require modification, although those modifications are likely to
be simple.
Uses of the IF special form in dialects which allow keyword-driven
extensions (or other incompatible extensions) to IF would be
affected syntactically. Non-portable program-understanding tools
for those dialects (including the interpreter and compiler) would
be impacted as well.
Aesthetics:
Some people like the IF body idea and find it more visually
aesthetic than the more-parenthesized (and incidentally also
more-indented) COND alternative.
Some people really dislike the idea of an IF body because they
feel it would destroy the symmetry of the THEN and ELSE clauses
in an IF expression, and would lead to a visually confusing format.
The IF-BODY:YES proposal does not preclude a self-imposed
programming style which uses no more than 3 arguments. In that
sense, it leaves the style issue up to the individual programmer.
Discussion:
A big chunk of the discussion around this proposal centered on
the form of the arguments rather than on the proposal itself.
The issue of whether the fact that some implementations had
chosen to extend IF should influence the future of Common Lisp
was debated.
Pitman:
This is a source of frustration for users, only a few of whom
care about arguing about whether more than three arguments is
aesthetic. They just want their programs to port without hassle.
CLtL has egged on the problem by explicitly suggesting that
such extensions were permissible.
Fahlman:
Whatever we decide about the merits of this proposal itself,
I want to VEHEMENTLY OBJECT to the rationale put forward in
[the first draft of] this proposal ... it is an extremely bad
precedent ... This same argument could be used to slip any
number of unspeakable horrors into the language....
Moon:
The mere fact that some people like this extension is not
sufficient reason to put it into the language, but it is
certainly sufficient reason to -discuss- putting it into the
language.
Steele:
I agree with Scott's assessment of the IF-BODY proposal (though
I think the proposal was worth making). I would point out that
one of the reasons for including IF in the language is to have
a simple primitive that can easily be recognized, by people and
by program-walkers alike, as being the simplest conditional and
not having implicit PROGNs as do WHEN, UNLESS, and COND.
Pitman:
Experience has shown that implementations are going to disagree
in a way that thwarts portability until we do something about it.
Both the extended dialect and the non-extended dialect are
within their rights. No individual dialect is at fault when
programs do not port correctly due to this problem; rather,
we are at fault for having provided a specification which
promotes this sort of problem.
To me, the question is not "Should we do something?" but rather
"What should we do?". I see only two choices: We can -require-
implementations to signal an error if there is ever more than
3 arguments to an IF or we can extend the language to make the
case of more than 3 arguments be well-defined in some interesting
way.
If we voted to disallow extensions to IF altogether, I'd want to
be able to justify that to our installed customer base. I can
imagine myself telling people they couldn't use the extended
case any more because it was cluttering the otherwise simple
syntax of Common Lisp -- I'd get laughed out of the room. All
someone would have to do to break down my argument would be to
compare the impact of this syntax extension to those already
present in LAMBDA or DEFUN. In truth, program understanding
programs have considerably more formidable problems than worrying
about whether IF has symmetric arguments, so I just don't buy
this counter-argument that some have presented.
Users don't care that IF and COND were introduced at differing
syntactic layers. They just care that the total space of
constructs available is adequately expressive, easy to modify,
etc. For those who are content to simply not use these
extensions, those needs are trivially easy to satisfy. For
those who -do- use those extensions, I'd like to have more
than a gold star to offer them in exchange for the expressive
power I'd be removing by making the if-body case illegal.
∂19-Apr-87 2054 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: COMPILER-WARNING-STREAM (Revision 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Apr 87 20:54:05 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 119728; Sun 19-Apr-87 23:53:52 EDT
Date: Sun, 19 Apr 87 23:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILER-WARNING-STREAM (Revision 4)
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295346987.BABYL@C.CS.CMU.EDU>
Message-ID: <870419235327.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 17 Apr 1987 20:38 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Status: Released. This version slightly revised to incorporate Dussud's
comment about the effect of this change on Dribble and to clean up some
awkward wording.
Although an earlier version of this was released, my feeling is that if a
semantic modification is made to a released proposal, the proposal should
become unreleased pending discussion in committee so that copies of it don't
accidentally get distributed too widely before there's been a chance for
internal review of `obvious' problems.
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
Revision 2 at committee meeting 15-Mar-87 14:18:56
Revision 3 reformat by Masinter 15-Mar-87 17:42:10
Revision 4, minor revision by SEF 15-Apr-87
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be specified what stream such warnings are printed on.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.
As a corollary of this, DRIBBLE is required to record from
*ERROR-OUTPUT* as well as *STANDARD-INPUT* and *STANDARD-OUTPUT* so that
it can record any compiler warnings that may be generated while it is in
effect.
I'm worried about potential unintended consequences of a proposal to change
DRIBBLE that piggybacks on this proposal.
For example, I could easily imagine someone doing
(SETQ *ERROR-OUTPUT* (OPEN filename1))
...stuff...
and then wanting a transcript so doing
(SETQ *ERROR-OUTPUT* (OPEN filename2))
(DRIBBLE filename3)
...stuff...
(DRIBBLE)
I would say their clear intent here is that *ERROR-OUTPUT* not be redirected.
I think that DRIBBLE is supposed to have no visible effect on the interaction
between (DRIBBLE file) and (DRIBBLE), so I'm surprised that it suggests
changing *STANDARD-INPUT* and *STANDARD-OUTPUT* rather than *TERMINAL-IO*.
Similar questions can be asked about *QUERY-IO* and *DEBUG-IO*.
My feeling is that the description of DRIBBLE needs lots of fixing as part of
a separate proposal unrelated to this one. I'm amenable to such a proposal, but
I don't think it belongs here because it requires further elaboration and
justification.
Rationale:
Compiler warning output is a widely accepted feature of compilation.
Warnings that come via the WARN function will go to the stream that is
the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is expected
to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear what stream receives the warnings.
Conversion Cost:
Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.
The cleanup committee supports this change.
∂19-Apr-87 2110 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Apr 87 21:10:35 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 119735; Mon 20-Apr-87 00:10:32 EDT
Date: Mon, 20 Apr 87 00:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295374347.BABYL@C.CS.CMU.EDU>
Message-ID: <870420001008.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
While I agree it might be somewhat expensive to filter duplicates in
some cases, I wonder how often the efficiency matters. In my personal
experience, DO-SYMBOLS and friends is never used in realtime because
it usually pages like crazy anyway.
In my code, it's generally used in environment initialization situations
where efficiency is not my chief concern, and where not making a mistake
is sometimes critical. I think it would be nicer if programmers didn't
have to worry about duplication. Sometimes I do very complicated package
surgery using DO-SYMBOLS where I think terrifying things might happen if
I hit a duplicate. Usually by the time I've debugged the code I make it
a goal to make repeat calls to the body not hurt things so I can test
the code more than once, but having it try to help me as much as
possible until I've gotten all the glitches out would be nice.
Does anyone care to make an estimate of exactly how much things get
slowed down if you don't duplicate any symbols and/or an estimate of how
often this slowdown would cause an adverse performance impact?
Including such assumptions in this proposal would be useful so that they
can be discussed or contested.
Personally, I'd rather see a keyword argument added someplace saying
that I'm willing to accept seeing duplications so that naive expectations
would not be violated in the default situation. As a straw man, something
like:
(DO-SYMBOLS (SYMBOL (FIND-PACKAGE "FRED") NIL
:ALLOW-DUPLICATES T
:EXTERNAL-ONLY NIL)
...)
Note that this could eliminate the need for DO-EXTERNAL-SYMBOLS...
∂19-Apr-87 2115 FAHLMAN@C.CS.CMU.EDU Issue: COMPILER-WARNING-STREAM (Revision 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87 21:15:21 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Apr 87 00:16:22-EDT
Date: Mon, 20 Apr 1987 00:16 EDT
Message-ID: <FAHLMAN.12295910980.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: COMPILER-WARNING-STREAM (Revision 4)
In-reply-to: Msg of 19 Apr 1987 23:53-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Although an earlier version of this was released, my feeling is that if a
semantic modification is made to a released proposal, the proposal should
become unreleased pending discussion in committee so that copies of it don't
accidentally get distributed too widely before there's been a chance for
internal review of `obvious' problems.
I agree.
As for KMP's substantive objections, the problem is that we have already
said too much about Dribble, and now we're caught in the game of trying
to specify it exactly. We can't standardize it in detail, since it
will have to be handled differently on different systems, depending on
the details of each system's user interface. It seems to me that the
two coherent possibilities are to eliminate it from the standard
altogether, or to say something like the following:
Some implemenations may provide a mechanism for saving a transcript of
the top-level user interaction (input and output) to a file. When such
a mechanism is present, it is conventionally turned on by (dribble
<pathname>) and is turned off by (dribble). Period.
-- Scott
∂19-Apr-87 2134 FAHLMAN@C.CS.CMU.EDU Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87 21:34:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Apr 87 00:35:01-EDT
Date: Mon, 20 Apr 1987 00:34 EDT
Message-ID: <FAHLMAN.12295914368.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
In-reply-to: Msg of 20 Apr 1987 00:10-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
It's hard to estimate the cost of eliminating duplicates in DO-SYMBOLS.
The obvious strategy is to cons up (or keep around) a hash-table and to
note symbols as they go by. That would be a big hash-table for some
packages, and might double the paging required (or push a non-paging
program into thrash-land. Let's guess that it doubles the time required
on the average.
I wouldn't mind adding a non-duplicating version of DO-SYMBOLS, as long
as this isn't the default. I don't want to pay the price for KMP's
occasional hairy applications every time I scan the symbol table looking
for something. I don't really object to the keyword idea (with
duplicates-allowed as the default), but the minimum-incompatibility
solution now would be to keep the two functions we have and add
DO-SYMBOLS-NO-DUPLICATES as either a new built-in function or a yellow
pages package for people who want it.
-- Scott
∂20-Apr-87 0625 DALY@IBM.COM Pavel's reply
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 06:25:36 PDT
Date: 20 April 1987, 09:21:28 EDT
From: Timothy Daly <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <042087.092128.daly@ibm.com>
Subject: Pavel's reply
Quite right. The missing # isn't missing. Mea Culpa.
∂20-Apr-87 0658 FAHLMAN@C.CS.CMU.EDU Issue IF-BODY (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Apr 87 06:58:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Apr 87 09:54:07-EDT
Date: Mon, 20 Apr 1987 09:54 EDT
Message-ID: <FAHLMAN.12296016150.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue IF-BODY (Version 4)
In-reply-to: Msg of 19 Apr 1987 23:27-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
There are many ways in which we could present controversial issues like
this. The idea of having two separate proposals, one in favor of the
change and one against, is obviously insane. It is also unreasonable to
allow the last person to touch the propsal to write an essay favoring
one point of view, while everyone else's arguments get boiled down to a
few selected phrases and some ellipsis dots. Any reasonably fair way of
presenting this stuff is all right with me. Maybe the best approach is
to let KMP write up the proposal, state his case at length in a
"Discussion: Pro" section, and let the loyal opposition have more or
less equal space in a "Discussion: Con" section.
The only quibble I have with the pre-discussion part of KMP's
presentation is that he presents (COND (test then) (T {else}*)) as the
obvious translation, and then picks on this in the aesthetics section.
If we're going to argue aesthetics, I prefer the following translation:
(if test
(progn {then-clauses}*)
(progn {else-clauses}*))
Here is what I would propose for the Discussion:Con section. Others in
sympathy with this view are invited to contribute to this section:
---------------------------------------------------------------------------
On purely aesthetic grounds, I am opposed to this proposal because it
makes code harder to scan quickly (and since we all have to read Common
Lisp code written by others, this is not a situation where each user can
make his own choice). The three elements of the current IF expression
are easy to spot, and there is a symmetry between the THEN and the ELSE
clause; in the extended form, all the clauses tend to run together
visually into a large, amorphous body, and it is hard to locate the THEN
clause in the middle of all the others. If a programmer wants either
the THEN or the ELSE clause to be a PROGN, he should use an explicit
PROGN. The result is indeed "more parenthesized and indented"; this is
a virtue.
On aesthetic matters such as this, reasonable people may differ. If a
majority in the Common Lisp community favor the extended form of IF,
their taste should prevail, but this has not been the majority view when
this issue has come up in the past.
The remaining argument is that this extension should be added because
some dialects already support it, some users do not realize that this
usage is not legal Common Lisp, and that these users are inconvenienced
when they discover, "late in the development cycle", that their code
does not run on other machines. I believe that it would set a very bad
precedent to give this argument any weight whatsoever. To do so would
be to give each implementor a tool that could be used to force any
compatible extension, no matter how ill-advised, into the language
standard: simply add the extension to your own dialect, refuse to
provide any warnings to your users that they are using a non-standard
feature, and then petition the standards committee (on the users'
behalf) to add the extension to Common Lisp so that these poor users
won't be inconvenienced.
The original charter of Common Lisp made it clear that implementations
could add non-standard extensions, but that users who want their code to
be portable should use the standard language only. The proper way to
protect users from portability problems is for each implementation to
provide a compilation mode (or code-walking tool or whatever) that warns
about the use of non-portable extensions. It has been suggested that
such a mode should be required, but Moon has argued (correctly, in my
view) that this is an environment issue not appropriate for
standardization. So each implementation that chooses to extend the
language in some way must take responsibility for protecting its users
from the consequences; if it neglects to do so, its users should
complain to the implementors, not to the Common Lisp standards
committee.
So, to the two choices that KMP presents (forbid any extension to IF or
adopt this proposal), I would add a third choice: encourage (but do not
require) that extended implementions issue a warning when non-portable
constructs are used, and encourage users to make life hot for any vendor
who refuses to do this.
I would point out that in this case a code-walker or compiler can easily
detect the use of extended-IF, and that it would be trivial to provide a
tool that puts an explicit PROGN around the ELSE clauses. It doesn't
matter whether this happens "late in the development cycle" since it is
a trivial modification.
∂20-Apr-87 0658 preece%mycroft@gswd-vms.ARPA Bigosities
Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 20 Apr 87 06:58:24 PDT
Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/)
Message-Id: <8704201356.AA13978@gswd-vms.ARPA>
Date: Mon, 20 Apr 87 07:55:24 CST
From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@sail.stanford.edu
Subject: Bigosities
primerd!DOUG@ENX.Prime.PDN
> The concept that 64 bits could be construed as a reasonable integer
> limit is silly since there are many hardware architectures where a basic
> arithmetic operation can be done on 64 bits in both integer and floating
> point. Also 64 bits is only ~21 decimal digits.
----------
What has the size of the basic hardware operation size got to do with
anything? Frankly, as long as the standard doesn't specify a minimum
size for bignum coverage, I would say 64 bits would be conforming.
I have never done any Lisp coding myself (outside of tests of our
implementation) which required numbers bigger than 64 bits -- if I were
going out shopping for a CL for my own use, that restriction wouldn't
bother me.
The most important thing is that each implementation make its limits
clear, so that the porter knows if she has a chance of making the port
in less than geological time and so that the shopper knows whether
the implementation is suitable for the proposed use. I don't really
care whether the limits are encoded as constants or printed on paper,
but I would like the standard to require that they be available and
that they be separated into representational limits and space limits.
--
scott preece
gould/csd - urbana
uucp: ihnp4!uiucdcs!ccvaxa!preece
arpa: preece@gswd-vms
∂20-Apr-87 0805 gls@Think.COM bignums are bogus
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 08:04:56 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 20 Apr 87 09:54:32 EST
Date: Mon, 20 Apr 87 10:51 EDT
From: Guy Steele <gls@Think.COM>
Subject: bignums are bogus
To: Fahlman@c.cs.cmu.edu, sandra%orion@cs.utah.edu
Cc: common-lisp@sail.stanford.edu, gls@think.com
In-Reply-To: <FAHLMAN.12294960256.BABYL@C.CS.CMU.EDU>
Message-Id: <870420105121.1.GLS@BOETHIUS.THINK.COM>
I have a vague memory of sending to this mailing list, a couple of years
ago, the observation that one could have MOST-POSITIVE-BIGNUM and
MOST-NEGATIVE-BIGNUM, and probably each would occupy 1/3 of the total
memory space.
∂20-Apr-87 1027 RPG On the Kanji feature of Common Lisp
∂20-Apr-87 0042 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the Kanji feature of Common Lisp
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Apr 87 00:42:15 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07982; 20 Apr 87 3:41 EDT
Received: from utokyo-relay by RELAY.CS.NET id ab14315; 20 Apr 87 3:34 AST
Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA08435; Mon, 20 Apr 87 16:42:07 jst
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA14916; Mon, 20 Apr 87 16:33:09+0900
Date: Mon, 20 Apr 87 16:33:09+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8704200733.AA14916@tansei.u-tokyo.junet>
To: ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
Subject: On the Kanji feature of Common Lisp
Dear Bob Mathis,
Please suggest your idea on the contents of this mail.
Thank you.
Masayuki
--------------------------------------------------------
On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
We concluded that
1) we want to propose our specification to ANSI X3J13.
The specification is not so restrictive.
2) Prior to do so, One of the author, namely ida, will send
the whole contents to common-lisp@sail.stanford to get
reactions of the US colleagues.
3) The proposed date of submission to CL bboard is
on the week of May 11th.
4) We are ready to send a person to the next meeting
to explain our proposal.
5) The reactions on the CL bboard will be gathered, and will
be transfered to WG members as quick as possible.
(several of them have E-mail links to ida.)
We will try to discuss on the issue by E-mails as possible as we can.
(we have no ethernet-like link to USA, so we cannot reply immediately.)
we finished the first draft of the english version.
It was mainly translated by the person of Nippon Symbolics.
(Thanks Mr.Shiota.)
The size is 12 pages long in letter sized papers.
We will revise up and send it.
Masayuki Ida
∂20-Apr-87 1126 Pavel.pa@Xerox.COM Re: Issue IF-BODY (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 11:26:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 11:27:18 PDT
Date: 20 Apr 87 11:27 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue IF-BODY (Version 4)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Sun, 19 Apr 87 23:27 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870420-112718-1241@Xerox>
I oppose this proposal on two grounds:
1) I like very much the extremely simple syntax/semantics of the current
IF construct. Making the syntax assymetric is very ugly and, it seems
to me, likely to encourage programmers to negate otherwise reasonable
conditions in order to make the else clause be the one they need more
than one statement for. I agree with Scott here; the extra indenting is
a virtue, not a vice.
2) When users lose time due to being confused about which features are
non-standard, it is not proper to complain to the standards committee.
Rather, they should complain to the implementors who did not provide
them with an easy way to be warned about non-portable constructs.
Obviously, not all such extensions can be easily flagged by the
compiler, but it's trivial to notice and warn about uses of IF-BODY.
Pavel
∂20-Apr-87 1235 Moon@STONY-BROOK.SCRC.Symbolics.COM MULTIPLE-VALUE-OR, and Consing
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Apr 87 12:35:40 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 119912; Mon 20-Apr-87 13:23:57 EDT
Date: Mon, 20 Apr 87 13:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MULTIPLE-VALUE-OR, and Consing
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 18 Apr 87 19:34 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET
Message-ID: <870420132345.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 18 Apr 87 19:34 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
>I think more to the heart of the matter is that Common LISP needs a way to grab,
>inspect, and pass on an unknown number of multiple values without consing
> (and yes, avoiding consing can be crucial for real applications
> give the current state of the art for garbage collection
> on conventional hardware). It's possible that, using
>multiple-value-call, simply having some way of
>doing non-consing &rest arguments may be sufficient. ...
I whole-heartly agree that A) Unneccessary consing should always be avoided,
B) it would be great to have &rest args that don't cons.
I currently have plans to have a STACK-LIST declaration that declares that
a &Rest is stack-allocated (as well as WITH-STACK-LIST, ala Lisp Machines)
in my system. I would suggest that others consider this as well, but
of course, it is only a declaration that could be ignored.
(I already avoid consing for (&Rest ignore), which should be easy).
My point is that MULTIPLE-VALUE-OR can only be done efficiently by low-level
implementation-specific code, and thats why it should be in Common Lisp.
I don't think this conclusion follows from your previous paragraph.
If the proposed MULTIPLE-VALUE-OR can easily be implemented in terms of
existing primitives, such as MULTIPLE-VALUE-CALL, and would be efficient
if there were non-consing &rest arguments, and non-consing &rest arguments
are desirable for other reasons, then I think a more logical conclusion is
"because non-consing &rest arguments can only be done efficiently by low-level
implementation-specific code, they should be in Common Lisp."
By the way, I don't think a declaration for non-consing &rest arguments
should be necessary. It should be simple enough for any compiler to
recognize special cases such as the following, once implementors'
attention has been drawn to the desirability of such optimizations. Another
way of saying the same thing is that I think consing is an implementation
issue, not a language issue, just as much as whether integer multiplication
takes 1 microsecond or 10 microseconds.
(lambda (&rest values)
(when (first values)
(return-from block (values-list values))))
∂20-Apr-87 1236 Moon@STONY-BROOK.SCRC.Symbolics.COM Environment-Arguments
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Apr 87 12:35:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 119933; Mon 20-Apr-87 14:04:19 EDT
Date: Mon, 20 Apr 87 14:03 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Environment-Arguments
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295628211.BABYL@C.CS.CMU.EDU>
Message-ID: <870420140356.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 18 Apr 1987 22:23 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In mail several months ago, Moon said that he agreed with adding an
optional environment argument to MACRO-FUNCTION, but that for
consistency we should also add such an argument to SPECIAL-FORM-P,
SYMBOL-FUNCTION, and SYMBOL-VALUE.
I think that this is wrong. (Masinter apparently does too, but I'll
speak for myself.)
This facility isn't designed for writing debuggers; it is meant to allow
macro-expanding macros to operate properly. Macros sometimes need to
expand other macros at compile time so that they can do SETF-like
things. In accessing some otehr macro's definition, a macro should take
cognizance of any MACROLET definitions and of lexical function
definitions that might shadow a macro definition. Therefore, they need
to be able to call MACRO-FUNCTION with an environment arg.
I don't think the last sentence follows. The argument that leads up to it
is an argument that MACROEXPAND and MACROEXPAND-1 need to take an environment
argument. They already do. So the real reason for giving MACRO-FUNCTION
an environment arg must be something else; I forget what the reason given
a few months ago was, but I remember that I thought it applied equally well
to those other operations.
I don't think macros need to get at function definitions and values in
the same way. Function definitions do not have to be available at
compile time, nor do values. And special forms are immutable: they
cannot be redefined, so presumably they cannot be shadowed either.
I see no such restriction (special forms cannot be shadowed) in CLtL.
Adding such a restriction seems like a poor idea in view of the third
paragraph on page 57. In any case, it would be a poor idea to make
MACRO-FUNCTION and SPECIAL-FORM-P behave inconsistently with respect to
the lexical environment, because that could lead to a large body of user
code with the restriction that special forms cannot be shadowed wired
into its structure, and that in turn would make it difficult to lift
such a restriction, either in the language definition or in individual
implementations. A little forethought now will save a peck of trouble
later.
(Larry proposes to make this explicit as part of this proposal; I would
prefer to make it a separate proposal, but agree with the
clarification.)
So I don't believe that SPECIAL-FORM-P, SYMBOL-FUNCTION, or SYMBOL-VALUE
need an environment arg after all.
Dave, do you buy that analysis? If so, I'll propoduce a proposal along
the lines of what Larry sent out.
I don't buy the analysis at all for SPECIAL-FORM-P. I feel less strongly
about SYMBOL-FUNCTION and SYMBOL-VALUE, but I think your analysis is still
wrong there, if only because of inline functions and constant "variables".
∂20-Apr-87 1448 Masinter.pa@Xerox.COM Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 14:48:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 14:39:25 PDT
Date: 20 Apr 87 14:39 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 20 Apr 87 17:20 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu,
DUSSUD%Jenner%ti-csl.CSNet@relay.cs.net
Message-ID: <870420-143925-1269@Xerox>
David,
Two things:
I can't imagine this proposal being adopted by X3J13 without some more
explaination, within the proposal itself, of how this proposal makes
CLOS easier. As it stands, it doesn't make the connection at all clear.
Second, since there will be a technical editor and an oversight
committee concerned with exact wording, I think that there will be
objections to a vote on any proposal which mandates exact wording. Thus,
although your description is coherent, I think it needs to be explained
in terms of what happens to Common Lisp, rather than the words in which
it is described.
I have no objection to the proposal itself.
Thanks,
Larry
∂20-Apr-87 1358 Masinter.pa@Xerox.COM Re: Issue IF-BODY (Version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 13:58:03 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 13:50:22 PDT
Date: 20 Apr 87 12:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue IF-BODY (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870420-135022-1113@Xerox>
I think we have discussed the pros and cons of this issue sufficiently,
to the point that it is counter-productive to repeat any of the
arguments. We have also agreed that, even though a majority of the
committee does not like this proposal, we want to release it. All we
need now is a version of the write-up which we can all agree to
distribute.
I support Scott's proposal for doing so, viz: "let KMP write up the
proposal, state his case at length in a `Discussion: Pro' section, and
let the loyal opposition have more or less equal space in a `Discussion:
Con' section."
Does anyone disagree? I think it would be best if Kent and Scott can
get a copy together privately and then mail it out as Version 5, so that
we can get this one off the table and proceed with some of the other
issues.
Thanks
Larry
∂20-Apr-87 1358 Masinter.pa@Xerox.COM Re: Issue: COMPILER-WARNING-STREAM (Revision 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 13:58:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 13:51:00 PDT
Date: 20 Apr 87 12:25 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: COMPILER-WARNING-STREAM (Revision 4)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Mon,
20 Apr 87 00:16 EDT
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870420-135100-1125@Xerox>
Kent and Scott have pointed out some of the difficulties of
incorporating Dussand's suggestion into this proposal. I suggest we
revert to the previous version of the proposal, and add a note in the
Discussion section that this proposal does further specify the behavior
of DRIBBLE because of the problems of the current under-specification of
DRIBBLE.
We can independently consider proposals either to further specify (or to
broaden the possible behavior of) DRIBBLE, and relate it to
ERROR-OUTPUT.
OK?
∂20-Apr-87 1420 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Apr 87 14:20:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120087; Mon 20-Apr-87 17:20:41 EDT
Date: Mon, 20 Apr 87 17:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: CL-Cleanup@sail.stanford.edu
cc: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
Message-ID: <870420172029.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Status: New (but see "adoption cost" below) issue.
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Middle of p.60
First complete sentence on p.62
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 is the initial version. (Moon 4/20/87)
Problem Description:
CLtL says that only keyword symbols can be used as keyword names in &key
parameter specifiers. This seems to imply (although it is not actually
a logical consequence) that only keyword symbols can be used as keyword
names in calls to functions that take keyword arguments. (It is not a
logical consequence because the called function might have been
implemented a different way than with &key.)
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of keyword argument names; allow
any symbol, including NIL."
In the middle of p.60, change "each -keyword- must be a keyword symbol,
such as :start" to "each -keyword- must be a symbol, such as :start".
Add these sentences: "Keyword symbols are most commonly used, but any
symbol is valid. Non-keyword symbols are sometimes used to provide
isolation between packages, but unlike keywords they must be quoted by
callers of the function, making the syntax slightly less convenient.
NIL is a valid -keyword-, although it is unlikely that a stylish
programmer would choose to use it." Be careful about where the italics
go in those sentences.
Change the last word in the first complete sentence on p.62 from
"keyword" to "symbol".
On p.64, add the following two examples to illustrate the explicit
keyword syntax:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Rationale:
If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.
Current Practice:
Some implementations do not have the restriction that I propose to remove.
I don't know of any implementations that enforce the restriction, but
there might be one.
Some implementations have bugs that prevent NIL from working as a keyword
argument name, but allow all non-NIL symbols. One Symbolics version that
I checked had this bug.
Adoption Cost:
No existing programs will stop working. Some implementors might have to
rearrange their error checking slightly, but it should be very easy.
I was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but I may be wrong.
Benefits:
This will help with the object-oriented programming standard.
Conversion Cost:
None.
Aesthetics:
There will probably be an argument about whether the restriction is
more esthetic or less esthetic than the freedom, but in either case
the aesthetic effect is slight.
Discussion:
None yet.
∂20-Apr-87 1517 Masinter.pa@Xerox.COM status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 15:17:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 15:17:01 PDT
Date: 20 Apr 87 15:17 PDT
From: Masinter.pa@Xerox.COM
Subject: status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870420-151701-1366@Xerox>
We were asked at X3J13 not to batch up our proposals but to send them
out when ready. Can we send some out this week?
Here is my status file. Please mail corrections asap.
ADJUST-ARRAY-DISPLACEMENT (revision 1)
Received but not discussed.
Need volunteer to lead discussion, summarize positions.
remailed 7-apr-87
SEF volunteered to delegate.
(I thought I saw a message from SEF discussing this but I
cannot find it.)
COMPILER-WARNING-BREAK (revision 2)
not Released.
Questions on interaction with condition proposal.
Defer to error/signal/condition committee?
remailed 7-apr-87
SEF suggested KMP should work on.
COMPILER-WARNING-STREAM (Revision 4)
Rev 3 was released
Comment from Dussand, forwarded to cl-cleanup,
SEF edited 15-Apr, incorporating dribble check & minor cleanup
Revert to omit DRIBBLE specification?
DEFVAR-INITIALIZATION (Revision 3)
Released
remailed 7-apr-87
(final form)
DO-SYMBOLS-DUPLICATES (Revision 1)
mailed 7-apr-87
Revision 1 by SEF 17-apr
Not released, in discussion
Questions "is it really inefficient to require non-duplicates?"
Add more arguments?
ENVIRONMENT-ARGUMENTS (revision 1)
SEF volunteered to work over the proposal further.
Mailed 7-apr-87
SEF summarized issues 18-Apr
(in question: add env arguments to SPECIAL-FORM-P etc)
FLET-IMPLICIT-BLOCK (Revision 5)
Discussion & agreement on cl-cleanup.
revision by Fahlman, 17-Apr-87 to cl-cleanup
FORMAT-ATSIGN-COLON (Revision 3)
Released.
(final form, mailed 17-Apr-87)
FORMAT-OP-C (revision 1)
Discussed and agreed, final form not yet available
(with Moon's amendment)
Need volunteer.
FUNCTION-TYPE (revision 2)
General agreement on basic proposal.
Wording to be worked out.
Mailed 17-Apr-87
Fahlman volunteered to revise & run by RPG
IF-BODY (Version 4)
General agreement to recommend against.
Final form not yet available.
Version 4 mailed by KMP , 19-Apr-87
Debate over proposal summary: how to balance pro & con?
IGNORE-ERRORS
Discussed and agreed, final form not yet available
(LMM: Some objections, defer to error/signal committee?)
Need volunteer.
IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
Released
Should remove confusing "To further clarify: " which is
about INTERN and not IMPORT.
KEWYWORD-ARGUMENT-NAME-PACKAGE (Version 1)
Submitted by Moon 20 Apr 87.
PEEK-CHAR-READ-CHAR-ECHO
Agreed to be controversial
Need volunteer to summarize positions.
PRINC-CHARACTER:WRITE-CHAR
Discussed and agreed, final form not yet available
(write-char choice)
Need volunteer.
PROMPT-FOR
Agreed to be controversial
Need volunteer to summarize positions.
REMF-DESTURCTION-UNSPECIFIED
Not discussed
Need volunteer to check over, lead discussion.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
(Should FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Tabled, a subset which deals with only those functions that
don't work in positions will be separated out.
Need volunteer.
SHARPSIGN-BACKSLASH-BITS
No general agreement (the meeting notes read "we cringed")
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-PACKAGE
Discussed, without general agremenet.
Need volunteer to summarize positions.
TAILP-NIL
Received but not discussed
Need volunteer to lead discussion, summarize positions.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Discussed and agreed, final form not yet available
∂20-Apr-87 1653 Masinter.pa@Xerox.COM Re: Issue ADJUST-ARRAY-DISPLACEMENT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 16:53:13 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 APR 87 16:54:12 PDT
Date: 20 Apr 87 16:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue ADJUST-ARRAY-DISPLACEMENT
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
19 Apr 87 21:03 EDT
To: Fahlman@C.CS.CMU.EDU
cc: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <870420-165412-1492@Xerox>
I found the message. Sorry for the confusion.
ADJUST-ARRAY-DISPLACEMENT should be marked with status "Revision 1 by SEF, 18-Apr-87".
Is there any discussion?
∂20-Apr-87 1911 FAHLMAN@C.CS.CMU.EDU Issue: COMPILER-WARNING-STREAM (Revision 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Apr 87 19:10:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Apr 87 22:11:49-EDT
Date: Mon, 20 Apr 1987 22:11 EDT
Message-ID: <FAHLMAN.12296150451.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: COMPILER-WARNING-STREAM (Revision 4)
In-reply-to: Msg of 20 Apr 1987 15:25-EDT from Masinter.pa at Xerox.COM
Yes, I support reverting to the previous version of
Compiler-Warning-Stream (with no mention of Dribble) and that we
consider some fix to Dribble as a separate item.
-- Scott
∂21-Apr-87 0400 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Re: Bignums are bogus?
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 21 Apr 87 03:59:28 PDT
Received: from aiva.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP
id aa00334; 20 Apr 87 18:23 WET
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Mon, 20 Apr 87 19:21:25 GMT
Message-Id: <21105.8704201921@aiva.ed.ac.uk>
To: common-lisp@sail.stanford.edu
Subject: Re: Re: Bignums are bogus?
> From: Richard Fateman <fateman@edu.berkeley.mike>
> The point about bignums is that you don't have to check for them
> overflowing, because they don't. Something more dreadful happens first.
> That's why 64bit or 1kbit bignums are no good.
I agree. Bignums should be analogous to lists; representation based
sublimits on size are acceptable only if they are so large that they are
like running out of memory. True, arrays and floats have size limits for
individual objects, but why should bignums be analogous to arrays and not
to lists? Page 13 of Steele says "storage is automatically allocated as
necessary".
It's beginning to seem that this discussion may be even longer than the one
of compiling CASE, perhaps because it's more trivial :-).
∂21-Apr-87 0747 FAHLMAN@C.CS.CMU.EDU Environment-Arguments
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Apr 87 07:47:30 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 21 Apr 87 10:48:28-EDT
Date: Tue, 21 Apr 1987 10:48 EDT
Message-ID: <FAHLMAN.12296288180.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Environment-Arguments
Macros sometimes need to
expand other macros at compile time so that they can do SETF-like
things...
I don't think the last sentence follows. The argument that leads up to it
is an argument that MACROEXPAND and MACROEXPAND-1 need to take an environment
argument. They already do.
Right. I was confused (as usual). Let me take another crack at this.
First, I think that the issues should be re-separated, as they were
originally. I don't think the part about adding an environment argument
to GET-SETF-METHOD is controversial. Also, the business about whether
special forms and other such things can be shadowed should be broken out
into a separate proposal that we can discuss on its own merits; we don't
seem to share the same assumptions here.
That leaves the old MACRO-FUNCTION-ENVIRONMENT proposal. As Moon points
out, what macros really need to do is call MACROEXPAND on forms (or
parts of forms) that the user passes in; MACROEXPAND needs an
environment arg in order to do this, and it has one already.
The original MACRO-FUNCTION-ENVIRONMENT proposal contains the following
example:
(defmacro example (form &environment environment)
(let ((macro (macro-function (car form) <environment> ))
(when macro .... (funcall macro form) ...)
where the <environment> arg to MACRO-FUNCTION is not currently legal but
would be under the proposal. SETF-like forms need to do something like
the above code: check whether the form is a macro in the current lexical
context and, if so, expand it. Note, however, that instead of calling
MACRO-FUNCTION and then maybe FUNCALL, you could just let MACROEXPAND do
the whole job. The original Clisp designers, in their infinite wisdom,
decided that if you call MACROEXPAND on somehting not currently a macro,
it just returns the argument with a second value of NIL (meaning "not a
macro after all").
So I no longer see any motivation at all for MACRO-FUNCTION-ENVIRONMENT,
nor for adding an environment arg to SYMBOL-FUNCTION, etc. There may
well need to be some new machinery set up to deal with the aliasing
problem -- macros that change their meaning when executed in certain
lexical contexts -- but that is a big problem that is in the hands of
another committee, and we should do nothing until we see a comprehensive
proposal on how to handle macros elegantly in a lexical world.
If nobody can come up with a coherent argument for
MACRO-FUNCTION-ENVIRONMENT, I propose we drop this, approve the SETF
part of the proposal, and move on.
∂21-Apr-87 0814 Hvatum.DLAB@MIT-MULTICS.ARPA "Redefining" functions
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 08:13:49 PDT
Date: Tue, 21 Apr 87 01:02 EDT
From: Hvatum@MIT-MULTICS.ARPA
Subject: "Redefining" functions
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <870421050242.558425@MIT-MULTICS.ARPA>
From: Steve Bacher (Draper Lab)
From: Jim Kempf <kempf%hplabsc at HPLABS.HP.COM>
Subject: Re: Redefinition of Common Lisp Functions
To: common-lisp at SAIL.STANFORD.EDU
I guess I need to clarify my comments. I see two competing needs here:
1) On the one hand, system vendors and applications distributors
require the option of not allowing users to redefine Common
Lisp functions. Allowing users to do so makes supplying safe,
good quality software difficult because regression testing becomes next to
impossible.
2) On the other, researchers and people prototyping advanced
applications might want to modify the semantics of certain
Common Lisp functions for experimental purposes.
I had in mind a third need:
3) User specifying a function whose name happens to conflict with the
name of an already existing LISP function, not with the intent of
changing the behavior of the LISP function, but with the purpose of
defining a new function for use with that user's code only.
The user may not know that the function already exists, and therefore
will not qualify or shadow it wrt the package system or use FLET.
Even if a non-used function name is chosen, who is to say that CL
version II won't chew up that name and (depending on the implementation)
break this guy's system?
Conceivably the LISP system could be compiled so that calls to any
built-in CL functions are done in a special "fast-call" way which
bypasses actually referencing the function cells of those symbols.
(Especially true for inline code.) Of course, this has the effect
of making CommonLOOPS-style function-redefining impossible, but
there ought to be other solutions to that problem. Which is the
subject of another discussion that I don't feel qualified to
participate in.
- SEB
≠
∂21-Apr-87 0814 Hvatum.DLAB@MIT-MULTICS.ARPA Compiling CASE
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 08:13:14 PDT
Date: Tue, 21 Apr 87 01:02 EDT
From: Hvatum@MIT-MULTICS.ARPA
Subject: Compiling CASE
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <870421050209.453617@MIT-MULTICS.ARPA>
From: Steve Bacher (Draper Lab)
From: Rob MacLachlan <RAM at C.CS.CMU.EDU>
The package system will not protect Common LISP from having
its functions redefined, since a user who wants to define
his/her own CAR function will likely not call it USER:CAR;
thus, since there is already a CAR in the LISP package, that's
the one that will get defined.
This is what SHADOW is for.
But the point is that it still requires a specific user action which
presumes knowledge that a built-in CL function is being redefined,
be it explicit package prefixing or use of SHADOW.
...it is not reasonable to redefine system functions.
True. However, if a programmer uses a name like ENCODE-UNIVERSAL-TIME
as a "local" function (in the Franz sense?), such that the compiler
doesn't make its definition globally available, this should be no
problem. I guess FLET is the solution here. Otherwise, the LISP
system should probably issue a warning, and possibly rename the
function internally (where possible).
I do not have in mind "redefining" CL functions in the sense of
changing the behavior of pieces of the LISP system that use them.
Rather, I mean defining new functions which happen to have names that
are the same as existing CL functions. If the system is set up so as
to protect itself properly from having pieces of itself suddenly
change their behavior, there should be no problem. I think that if
guidelines similar to those above are followed, programs that define
functions with the same names as CL functions (NOT "redefine" those
functions) can be portable.
One more point: If you say that portability precludes
implementation-dependent constructs, then we no longer have different
CL-compatible implementations - just a single CL implementation with
different code generators for different hardware. Maybe this is what
we all REALLY want. Who knows?
Of course internal compiler representations are highly
implementation dependent, but this isn't necessarily a problem.
One of the main things that source code walkers have been used
for is writing "optimizing macros" for non-optimizing compilers.
As long as the compiler adequately optimizes the code, macros can
expand in a simple-minded way without understanding their
arguments.
Let's not try to unload the total optimizing burden on the compiler.
Surely there are situations where a macro is in a far better position
to know how to optimize a particular construct than the compiler,
whose job is to optimize the general cases.
Also, as far as internal representation of source code is concerned,
no matter how fancy your compiler is, there's always got to be a
phase where real source code is analyzed and converted to whatever
internal form you like. Certainly transformations can be invoked
at that level. What's more, user-written transformations necessarily
operate on the source code, unless a LISP implementation is required
to make its compiler's internal representation open for manipulation.
- SEB
≠
∂21-Apr-87 0918 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue ADJUST-ARRAY-DISPLACEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 09:18:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120118; Mon 20-Apr-87 17:51:49 EDT
Date: Mon, 20 Apr 87 17:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295875812.BABYL@C.CS.CMU.EDU>
Message-ID: <870420175130.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Unlike many of the other issues being discussed, this is one on which
I might be expected to have an opinion.
Current practice: Symbolics implements what is proposed, except for
(4) A is displaced to B before the call, but not displaced afterward. A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :initial-element.
We never copy the contents of B in this case; all elements are taken from
the :initial-element.
Either behavior seems equally justifiable to me. One could say
"adjust-array never stores into the array if it ends up displaced" or
"adjust-array only preserves the elements of non-displaced arrays." I
have no information as to whether it matters to users.
∂21-Apr-87 0919 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FLET-IMPLICIT-BLOCK (Revision 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 09:19:32 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120124; Mon 20-Apr-87 18:02:02 EDT
Date: Mon, 20 Apr 87 18:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FLET-IMPLICIT-BLOCK (Revision 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295308952.BABYL@C.CS.CMU.EDU>
Message-ID: <870420180149.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve, let's release this.
∂21-Apr-87 0920 Moon@STONY-BROOK.SCRC.Symbolics.COM Environment-Arguments
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 09:19:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120130; Mon 20-Apr-87 18:13:24 EDT
Date: Mon, 20 Apr 87 18:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Environment-Arguments
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12295628211.BABYL@C.CS.CMU.EDU>
References: <870407-174210-2710@Xerox>
Supersedes: <870420140356.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870420181313.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
[This is a revised version of my previous missive, revised after
reading the referenced message, which was From: Masinter.pa@Xerox.COM
Subject: Issue: ENVIRONMENT-ARGUMENTS (Revision 1)]
Date: Sat, 18 Apr 1987 22:23 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In mail several months ago, Moon said that he agreed with adding an
optional environment argument to MACRO-FUNCTION, but that for
consistency we should also add such an argument to SPECIAL-FORM-P,
SYMBOL-FUNCTION, and SYMBOL-VALUE.
I think that this is wrong. (Masinter apparently does too, but I'll
speak for myself.)
This facility isn't designed for writing debuggers; it is meant to allow
macro-expanding macros to operate properly. Macros sometimes need to
expand other macros at compile time so that they can do SETF-like
things. In accessing some otehr macro's definition, a macro should take
cognizance of any MACROLET definitions and of lexical function
definitions that might shadow a macro definition. Therefore, they need
to be able to call MACRO-FUNCTION with an environment arg.
I don't think the last sentence follows. The argument that leads up to it
is an argument that MACROEXPAND and MACROEXPAND-1 need to take an environment
argument. They already do. So the real reason for giving MACRO-FUNCTION
an environment arg must be something else; I forget what the reason given
a few months ago was, but I remember that I thought it applied equally well
to those other operations.
The reason for changing MACRO-FUNCTION given in the 2nd referenced
message is for macros that do their own macroexpansion, calling the
macro expander function directly instead of going through MACROEXPAND.
I think that that is a separate issue from fixing SETF so that it can
pass the correct arguments to MACROEXPAND-1 for macros defined with
MACROLET, and should be proposed/debated separately.
I don't think macros need to get at function definitions and values in
the same way. Function definitions do not have to be available at
compile time, nor do values. And special forms are immutable: they
cannot be redefined, so presumably they cannot be shadowed either.
I see no such restriction (special forms cannot be shadowed) in CLtL.
Adding such a restriction seems like a poor idea in view of the third
paragraph on page 57. In any case, it would be a poor idea to make
MACRO-FUNCTION and SPECIAL-FORM-P behave inconsistently with respect to
the lexical environment, because that could lead to a large body of user
code with the restriction that special forms cannot be shadowed wired
into its structure, and that in turn would make it difficult to lift
such a restriction, either in the language definition or in individual
implementations. A little forethought now will save a peck of trouble
later.
(Larry proposes to make this explicit as part of this proposal; I would
prefer to make it a separate proposal, but agree with the
clarification.)
So I don't believe that SPECIAL-FORM-P, SYMBOL-FUNCTION, or SYMBOL-VALUE
need an environment arg after all.
Dave, do you buy that analysis? If so, I'll propoduce a proposal along
the lines of what Larry sent out.
I don't buy the analysis at all for SPECIAL-FORM-P. I feel less strongly
about SYMBOL-FUNCTION and SYMBOL-VALUE, but I think your analysis is still
wrong there, if only because of inline functions and constant "variables".
I feel that MACRO-FUNCTION should be discussed together with SPECIAL-FORM-P,
SYMBOL-FUNCTION, and SYMBOL-VALUE, and should be discussed separately from
GET-SETF-METHOD, GET-SETF-METHOD-MULTIPLE-VALUE, and DEFINE-SETF-METHOD.
I'm strongly opposed to burying
Clarify that it is an error to use FLET/LABELS/MACROLET on any of the
symbols defined in CLtL as designating special forms.
in the middle of another proposal; it should be proposed and discussed
on its own (lack of) merits. The 2nfd referenced message incorporates
a message from me explaining why I think this proposal is unworkable.
∂21-Apr-87 0921 KMP@STONY-BROOK.SCRC.Symbolics.COM IF-BODY
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 09:20:53 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120149; Mon 20-Apr-87 19:08:48 EDT
Date: Mon, 20 Apr 87 19:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF-BODY
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12296016150.BABYL@C.CS.CMU.EDU>
Message-ID: <870420190818.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Funny you objected to my changing the (IF test then (PROGN {else}*))
to (COND (test then) (T {else}*)). I did that to help your case. I
consider the former to be so ugly that I never use it in any code, while
I don't find COND to be so ugly that I wouldn't sometimes use it. I
was honestly trying to keep things as balanced as possible. I guess
the situation is just very complicated and requires both rewrites to
be illustrated...
By the way, I was surprised that the copy I was working with (done by
Masinter) had left out Fahlman's IF-BODY:NO suggestion, but I assumed
that I had just mis-remembered what we discussed at the in-person
meeting and that we'd decided for some reason not to make ballot items
for proposals that amount to the status quo...
I'm happy to work with you on a revised proposal that feels balanced
as suggested in today's mail from Masinter. Why don't you send me
something privately which you think feels more balanced -- ie, factor
back in the earlier arguments in a way you feel comfortable with and
we'll go from there, reporting back to the committee when we're in
agreement.
-kmp
∂21-Apr-87 1051 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 10:51:23 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120687; Tue 21-Apr-87 13:50:53 EDT
Date: Tue, 21 Apr 87 13:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870420-143925-1269@Xerox>
Message-ID: <870421135040.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 20 Apr 87 14:39 PDT
From: Masinter.pa@Xerox.COM
I can't imagine this proposal being adopted by X3J13 without some more
explanation, within the proposal itself, of how this proposal makes
CLOS easier. As it stands, it doesn't make the connection at all clear.
Do you really think that's appropriate? If you do, I'll try to write some,
but I didn't think cleanup proposals were supposed to contain that sort of
discussion. Maybe it would be better to remove all reference to CLOS and
simply say that there are applications both existing and proposed that use
packaged (i.e. non-keyword) symbols as &key argument names? Or would it
be better to leave in the specific reference to CLOS?
Second, since there will be a technical editor and an oversight
committee concerned with exact wording, I think that there will be
objections to a vote on any proposal which mandates exact wording. Thus,
although your description is coherent, I think it needs to be explained
in terms of what happens to Common Lisp, rather than the words in which
it is described.
I didn't mean to imply that that was mandated wording, only sample wording.
What I was really trying to do was to enumerate the places in the book
that would have to change.
I'll send out a revision 2 after this discussion converges.
∂21-Apr-87 1155 Moon@STONY-BROOK.SCRC.Symbolics.COM Environment-Arguments
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 11:55:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120808; Tue 21-Apr-87 14:55:46 EDT
Date: Tue, 21 Apr 87 14:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Environment-Arguments
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12296288180.BABYL@C.CS.CMU.EDU>
Message-ID: <870421145535.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 21 Apr 1987 10:48 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
If nobody can come up with a coherent argument for
MACRO-FUNCTION-ENVIRONMENT, I propose we drop this, approve the SETF
part of the proposal, and move on.
That sounds good to me.
∂21-Apr-87 1215 FAHLMAN@C.CS.CMU.EDU IF-BODY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Apr 87 12:14:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 21 Apr 87 15:15:51-EDT
Date: Tue, 21 Apr 1987 15:15 EDT
Message-ID: <FAHLMAN.12296336858.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: IF-BODY
In-reply-to: Msg of 20 Apr 1987 19:08-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I'm leaving town for a week, starting in about 20 minutes. In my view a
balanced presentation would consist of your version of the proposal, and
for discussion the long statement you included in the last version, plus
the rebuttal I sent out a day or two ago. If you're willing to leave it
at that, fine; else we'll have to iterate until someone gives up and
lets the other guy have the last word. rather than stall the process,
I'm happy to let someone else from the CON camp do the iterating in my
absence.
-- Scott
∂21-Apr-87 1222 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Apr 87 12:21:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 21 Apr 87 15:22:46-EDT
Date: Tue, 21 Apr 1987 15:22 EDT
Message-ID: <FAHLMAN.12296338085.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: Msg of 21 Apr 1987 13:50-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I can't imagine this proposal being adopted by X3J13 without some more
explanation, within the proposal itself, of how this proposal makes
CLOS easier. As it stands, it doesn't make the connection at all clear.
Do you really think that's appropriate? If you do, I'll try to write some,
but I didn't think cleanup proposals were supposed to contain that sort of
discussion. Maybe it would be better to remove all reference to CLOS and
simply say that there are applications both existing and proposed that use
packaged (i.e. non-keyword) symbols as &key argument names? Or would it
be better to leave in the specific reference to CLOS?
Whether you reference CLOS or just give a random example, I think some
sort of example is needed. I couldn't imagine a good reason for this
change. Keywords don't interfere with one another, so modularity is not
the issue in any obvious way, and I'm not sympathetic to making a change
just because some people would rather type 'FOO than :FOO. I'm sure
you've got a good reason for proposing this, and I'd like some
indication of what it is.
-- Scott
∂21-Apr-87 1253 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 12:53:28 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 120916; Tue 21-Apr-87 15:52:23 EDT
Date: Tue, 21 Apr 87 15:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: Fahlman@C.CS.CMU.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12296338085.BABYL@C.CS.CMU.EDU>
Message-ID: <870421155153.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I have had applications which for various reasons I can't go
into in detail where I needed to have a keyword which no one
but myself would use. That is,
(DEFUN FOO (&KEY ((PRIVATE-KEYWORD VAR) default) ...)
...)
I'm much happier about this than about
(DEFUN FOO (&KEY ANYONE-OTHER-THAN-KMP-WHO-USES-THIS-KEYWORD-DESERVES-TO-LOSE)
...)
I support allowing keyword designators to be in other than the keyword package.
∂21-Apr-87 1303 goldman@vaxa.isi.edu MULTIPLE-VALUES, consing, and clarity
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 Apr 87 13:03:26 PDT
Received: by vaxa.isi.edu (4.12/4.7)
id AA03718; Tue, 21 Apr 87 12:04:52 pst
Message-Id: <8704212004.AA03718@vaxa.isi.edu>
Date: 21 Apr 1987 1204-PST (Tuesday)
To: COMMON-LISP@SAIL.STANFORD.EDU
From: goldman@VAXA.ISI.EDU
Subject: MULTIPLE-VALUES, consing, and clarity
Cc: goldman@VAXA.ISI.EDU
I'm sure this must have been suggested long ago, but I'd at least like
to know why it is not part of common lisp:
From the point of view of writing clear code, as well as just good old
symmetry, it seems unfortunate that we have the richness of LAMBDA-LISTs
to pass information from calling environments into functions, but
only the impoverished
(MULTIPLE-VALUE-BIND Var* values-form ...) for communication in
the reverse direction. I have found numerous cases where my code
would be much clearer if I could write
(MULTIPLE-VALUE-BIND LAMBDA-LIST values-form ...), using
&rest, &key, and &optional receive parameters to help me "destructure"
the information coming back from values-form -- including default
values for optional parameters.
I bring this up (again?) now only because of recent discussions
about multiple values and consing. If I could write
(multiple-value-bind (&rest values) values-producer
(cond ((test values) (values-list values))
...))
a good compiler could recognize that there was no need to cons up a list
of values only to spread (a tail of) the list back onto the stack.
[Of course, this is NOT upward compatible with the current
multiple-value-bind, since the current one allows a mismatch
between the number of variables being bound and the number of
values being returned. How did THAT find its way into the specification,
anyway? I suppose its an attempt to reduce the need for
multiple-value-list when you don't know how many values might come back?]
The main objection I see to allowing a lambda list is with maintenance --
adding additional return values from a function F could invalidate calls
on F that were not prepared to accept (even if only to ignore) them.
∂21-Apr-87 1425 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM MULTIPLE-VALUES, consing, and clarity
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 21 Apr 87 14:25:13 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 78601; 21 Apr 87 17:24:18 EDT
Date: Tue, 21 Apr 87 17:24 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: MULTIPLE-VALUES, consing, and clarity
To: goldman@VAXA.ISI.EDU, COMMON-LISP@SAIL.STANFORD.EDU
In-Reply-To: <8704212004.AA03718@vaxa.isi.edu>
Message-ID: <870421172431.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: 21 Apr 1987 1204-PST (Tuesday)
From: goldman@VAXA.ISI.EDU
I'm sure this must have been suggested long ago, but I'd at least like
to know why it is not part of common lisp:
MULTIPLE-VALUE-CALL. (Naively, MULTIPLE-VALUE-BIND is a macro that
turns into MULTIPLE-VALUE-CALL with a lambda-list of
(&optional ,@varlist &rest ignore)
]
∂21-Apr-87 1506 Pavel.pa@Xerox.COM Re: MULTIPLE-VALUES, consing, and clarity
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Apr 87 15:06:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 APR 87 15:07:53 PDT
Date: 21 Apr 87 15:07 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: MULTIPLE-VALUES, consing, and clarity
In-reply-to: goldman@VAXA.ISI.EDU's message of 21 Apr 87 12:04 PST
(Tuesday)
To: goldman@VAXA.ISI.EDU
cc: COMMON-LISP@SAIL.STANFORD.EDU
Message-ID: <870421-150753-2649@Xerox>
If you want to say
(MULTIPLE-VALUE-BIND LAMBDA-LIST values-form ...)
you can always say instead
(multiple-value-call #'(lambda LAMBDA-LIST ...) values-form)
The proverbial good compiler can still do the optimization you
mentioned. If you don't like the syntax (and who could blame you), you
could always make a macro for it.
Pavel
∂21-Apr-87 1450 Pavel.pa@Xerox.COM [Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Apr 87 14:50:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 APR 87 13:54:46 PDT
Date: 21 Apr 87 13:54 PDT
From: Pavel.pa@Xerox.COM
Subject: [Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:
Environment-Arguments]]
To: CL-Cleanup@SAIL.Stanford.Edu
cc: Gregor.pa@Xerox.COM
Message-ID: <870421-135446-2536@Xerox>
I asked Gregor what he thought about not giving the environment argument
to macro-function. This is his response.
Pavel
----- Begin Forwarded Messages -----
Date: 21 Apr 87 13:18 PDT
From: Gregor.pa
Subject: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:
Environment-Arguments]
In-reply-to: Pavel.pa's message of 21 Apr 87 12:12 PDT
To: Pavel.pa
cc: Gregor.pa
Well I would have to see the macros committe stuff (whenever that gets
done) to know for sure, but even macro-function-environment is less than
you really need. You also need to be able to build the env arg to
macroexpand-1. The screw case is a macro which is so hairy that it
needs to be able to take an environment, and then macroexpand its body
in an environment which is "slightly different" than that environment.
The problem is that macroexpanding, in general, means yielding control
over who gets to do the macroexpansion to some other code. That other
code might call macroexpand itself and so it must be able to provide a
suitable second argument.
Here is the canonical example:
(defmacro my-hairy-macro (&body body &environment e)
(walk-form body e#'(lambda ...)))
my hairy macro is a macro like with-slots which needs to walk its body,
macroexpanding the whole thing and perhaps replacing parts of it. Like
many macros, it needs to take the environment argument in because it is
going to have to call macroexpand on its body to work.
But this macro passes its environment to the walker. In order to do its
job, the walker is going to have to be able to augment that environment
structure and be able to pass it back to macroexpand. The rest of the
example is.
(defmacro foo () ''loser)
(my-hairy-macro
(macrolet ((foo () ''winner))
(my-hairy-macro
(foo))))
When the walker "walks down into" the body of the macrolet, it needs to
be able to make a new lexical environment which includes the previous
lexical environment plus a (in this case new) definition for FOO.
Perhaps a nice thing would be for the second argument to macroexpand to
really be a function, this function (if supplied) is the actual
macroexpansion function to call. These functions would be lexical
closures over what we now think of as the environment. People could use
standard lexical closure techniques for augmenting environments. The
combination language for 'building' environments would be Lisp, it would
be a win for all the standard reasons.
----- End Forwarded Messages -----
∂21-Apr-87 1655 Moon@STONY-BROOK.SCRC.Symbolics.COM MULTIPLE-VALUES, consing, and clarity
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 16:54:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121218; Tue 21-Apr-87 19:54:57 EDT
Date: Tue, 21 Apr 87 19:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MULTIPLE-VALUES, consing, and clarity
To: goldman@VAXA.ISI.EDU
cc: COMMON-LISP@SAIL.STANFORD.EDU
In-Reply-To: <8704212004.AA03718@vaxa.isi.edu>
Message-ID: <870421195424.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
This was discussed at enormous length early in the design of Common Lisp.
Most of the mail discussions, draft manuals, and ballots have been archived,
so if you really care that much, it's possible to reconstruct the discussion.
I'll just say here that at one time MULTIPLE-VALUE-BIND did allow & keywords,
but it was changed.
∂21-Apr-87 1659 Moon@STONY-BROOK.SCRC.Symbolics.COM [Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 16:59:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121221; Tue 21-Apr-87 19:59:11 EDT
Date: Tue, 21 Apr 87 19:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Gregor.pa: Re: ["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>:
Environment-Arguments]]
To: Pavel.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.Edu, Gregor.pa@Xerox.COM
In-Reply-To: <870421-135446-2536@Xerox>
Message-ID: <870421195859.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
What I read from Gregor's comments (as well as our own similar experiences) is
that merely adding an optional argument to macro-function is not enough. To
support the full generality of code walkers, it would be necessary to define
standard operations for manipulating lexical environments, making them more
"first class" than at present in Common Lisp, where they can be passed around
but their structure is undefined. I would hope that we could do this in an
abstract way, so that lexical environments were not constrained to be
implemented in one particular way.
This sounds like a fine thing, but a little beyond the scope of the cleanup
committee.
∂21-Apr-87 2309 MURRAY%cs.umass.edu@RELAY.CS.NET MULTPLE-VALUE-OR &rest args
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 21 Apr 87 23:09:30 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab26960; 22 Apr 87 2:07 EDT
Received: from cs.umass.edu by RELAY.CS.NET id bl27373; 22 Apr 87 1:58 AST
Date: Tue, 21 Apr 87 15:45 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SAIL.STANFORD.EDU
Subject: MULTPLE-VALUE-OR &rest args
X-VMS-To: CLMAIL
>I think more to the heart of the matter is that Common LISP needs a way to grab,
>inspect, and pass on an unknown number of multiple values without consing
> (and yes, avoiding consing can be crucial for real applications
> give the current state of the art for garbage collection
> on conventional hardware). It's possible that, using
>multiple-value-call, simply having some way of
>doing non-consing &rest arguments may be sufficient. ...
I whole-heartly agree that A) Unneccessary consing should always be avoided,
B) it would be great to have &rest args that don't cons.
I currently have plans to have a STACK-LIST declaration that declares that
a &Rest is stack-allocated (as well as WITH-STACK-LIST, ala Lisp Machines)
in my system. I would suggest that others consider this as well, but
of course, it is only a declaration that could be ignored.
(I already avoid consing for (&Rest ignore), which should be easy).
My point is that MULTIPLE-VALUE-OR can only be done efficiently by low-level
implementation-specific code, and thats why it should be in Common Lisp.
>I don't think this conclusion follows from your previous paragraph.
>If the proposed MULTIPLE-VALUE-OR can easily be implemented in terms of
>existing primitives, such as MULTIPLE-VALUE-CALL, and would be efficient
>if there were non-consing &rest arguments, and non-consing &rest arguments
>are desirable for other reasons, then I think a more logical conclusion is
>"because non-consing &rest arguments can only be done efficiently by low-level
>implementation-specific code, they should be in Common Lisp."
Are you just pointing out a flaw in my logic, or are you suggesting that
Common Lisp REQUIRE certain &rest args to not cons? The last sentence
was not meant to logically follow from the previous -- I was merely
re-iterating my point in requesting a MULTIPLE-VALUE-OR form, which is it
can be efficiently implemented WITHOUT non-consing rest args. I might
also add that using MULTIPLE-VALUE-CALL is going to require both
a Lambda and a Block, in which the Return-From will end up being a Throw.
It might not Cons, but I wouldn't call that "Efficient" (Maybe Symbolics does
function calls and throws more efficiently than a couple tests and a branch?
If so, that is exactly why it should be in Common Lisp -- You do it your way,
I'll do it mine).
>By the way, I don't think a declaration for non-consing &rest arguments
>should be necessary. It should be simple enough for any compiler to
>recognize special cases such as the following, once implementors'
>attention has been drawn to the desirability of such optimizations. Another
>way of saying the same thing is that I think consing is an implementation
>issue, not a language issue, just as much as whether integer multiplication
>takes 1 microsecond or 10 microseconds.
> (lambda (&rest values)
> (when (first values)
> (return-from block (values-list values))))
I guess you are saying Common Lisp shouldn't REQUIRE any &rest args not to cons.
I certainly agree - it is properly in the domain of Optimizations. A declaration
may not be always be necessary, but this is just about in the same category
as determining whether a function has side-effects. You can sometimes prove
it doesn't, but why go to all the bother if a very knowledgable and intelligent
(compared to a compiler) programmer can simply tell you?
- Kelly Murray
∂22-Apr-87 1116 rauen@CLS.LCS.MIT.EDU Streams
Received: from CLS.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Apr 87 11:16:37 PDT
Received: by CLS.LCS.MIT.EDU (4.12/4.7); Wed, 22 Apr 87 12:55:04 est
From: rauen@CLS.LCS.MIT.EDU (James R. Rauen)
Message-Id: <8704221755.AA00926@CLS.LCS.MIT.EDU>
Date: 22 Apr 1987 1254-EST (Wednesday)
To: common-lisp@sail.stanford.edu
Subject: Streams
I'm encountering some difficulties with synonym streams. Let's say I
do the following:
(defvar a *standard-input*)
(defvar b *standard-output*)
(defvar c (make-synonym-stream 'a))
(defvar d (make-synonym-stream 'b))
(defvar e (make-two-way-stream c d))
(setq a *standard-output*)
Now stream C has been turned into an output stream. What is E now?
What does it answer to INPUT-STREAM-P? I can also cause trouble by
changing the value of a synonym stream's variable from a character
stream to a byte stream.
--Jim
∂22-Apr-87 1232 KMP@STONY-BROOK.SCRC.Symbolics.COM ASSOC-RASSOC-IF-KEY (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Apr 87 12:32:27 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121957; Wed 22-Apr-87 15:14:43 EDT
Date: Wed, 22 Apr 87 15:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ASSOC-RASSOC-IF-KEY (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: GLS@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870422151450.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: ASSOC-RASSOC-IF-KEY
References: ASSOC-IF (p280), ASSOC-IF-NOT (p280), RASSOC-IF (p281),
RASSOC-IF-NOT (p281)
Category: CLARIFICATION/ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The descriptions of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT
do not mention a :KEY option.
Proposal (ASSOC-RASSOC-IF-KEY:YES):
Allow a :KEY keyword for ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF, and RASSOC-IF-NOT.
If not supplied, it should default to #'IDENTITY as do the :KEY keywords
for other -IF and -IF-NOT functions.
Rationale:
All the other -IF and -IF-NOT variations of list operations omit the
:TEST and :TEST-NOT keywords, but allow :KEY. For example, consider
the family of MEMBER, MEMBER-IF, and MEMBER-IF-NOT. The omission of
:KEY in this situation in CLtL was probably an oversight.
Current Practice:
The Symbolics implementation went ahead and added :KEY.
I suspect that implementations are split down the middle on
whether this is offered.
Adoption Cost:
A small amount of additional code is necessary to support this in
implementations not already offering it as an extension.
Benefits:
This would make the set of -IF and -IF-NOT functions be more regular in
their calling conventions.
Conversion Cost:
The change is essentially upward compatible with user code.
Aesthetics:
Although this introduces additional mechanism, it does so in a way that
probably makes it easier to think about which functions do what, so it
would likely be seen as a simplification.
Discussion:
KMP supports this change/clarification.
∂22-Apr-87 1343 KMP@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Apr 87 13:43:20 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 122090; Wed 22-Apr-87 16:42:48 EDT
Date: Wed, 22 Apr 87 16:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870422164300.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: AREF-1D
References: Arrays (pp286-298)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying
arity. Currently, you have to make a displaced array to work with
temporarily and then throw away the displaced array when you're done.
In the case of FILLARRAY, I find this bothersome because there is no
a priori reason why FILLARRAY should have to cons at all.
Proposal (AREF-1D:YES):
Introduce a new function AREF-1D which allows 1D access to the storage
backing up a given array assuming the normal row-major storage layout.
This accessor should be valid for use with SETF.
Rationale:
We already document the row-major storage layout and have a number of
operators which allow users to exploit that order. This would be a
useful addition.
LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops which had the following form:
(DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
... (AREF-1D ARRAY I) ...)
Currently, the only really efficient way to write this involves
something like:
(ECASE (ARRAY-RANK ARRAY1)
((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
(DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
(SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
...some finite number of clauses...)
Current Practice:
Many implementations have this primitive under some other name
for use internally. In Symbolics systems, for example, it is SYS:%1D-AREF.
Adoption Cost:
This change is fairly localized. In implementations which already use
this primitive internally, it's little more than a matter of changing the
name of or otherwise releasing the existing primitive. In some implementations,
it might involve writing a small amount of code (and associated compiler
optimizers).
Benefits:
This gives users efficient access to something which they already have
inefficient access to.
Conversion Cost:
This is an upward-compatible change.
Aesthetics:
I think this allows certain programs to be written in a more aesthetic way.
Discussion:
KMP supports this change.
∂22-Apr-87 1351 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Apr 87 13:51:32 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 122107; Wed 22-Apr-87 16:51:08 EDT
Date: Wed, 22 Apr 87 16:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870422165116.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297)
Category: ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The description of ADJUST-ARRAY on pp297-298 says that it is ``not permitted
to call ADJUST-ARRAY on an array that was not created with the :ADJUSTABLE
option.''
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:OK):
Change the definition of ADJUST-ARRAY to say that any array is a valid argument.
Say that if the array is not adjustable or if its old rank is not compatible
with the newly specified rank, then a new array will be created and returned.
In the case where a new array is returned, an implementation is permitted to
(but not required to) recycle the storage backing up that array if it is also
willing to do appropriate error checking to assure that AREFs to that array
will signal an error. In other words, the actual pointer to the array cannot
be reclaimed unless the compiler can prove that there are no pointers to it
and if the array is not reclaimed, references through it must not point to
recycled storage. [Note: I'm flexible on this, but it seems about right. I'm
patterning this after `dead arrays' in Maclisp. --KMP]
As with other destructive operations (most of which have names starting with
the letter "N"), users would be encouraged to use this for value wherever
possible and would be told that they can rely on the array to be adjusted
`for effect' only when it was adjustable and the new rank matched the old.
Rationale:
ADJUST-ARRAY offers features which are offered by no other function and which
are useful in cases involving non-adjustable arrays (for what amounts to copying).
This change would allow an expression such as:
(SETQ X (ADJUST-ARRAY X ...))
to work reliably. Those desiring the old behavior could do:
(IF (OR (NOT (ADJUSTABLE-ARRAY-P X))
(NOT (EQUAL (ARRAY-RANK X) (LENGTH NEW-DIMENSIONS))))
(ERROR "Array cannot be adjusted."))
to get the old style error checking.
Current Practice:
Probably no one implements this extension.
Adoption Cost:
Although this change is not trivial, it is localized and would probably not
require an excessive amount of work to install. Probably most of the necessary
routines already exist and it's just a matter of offering an interface.
Benefits:
In cases where a user would want to adjust an array but the array is not
adjustable, he may well decide to try to simulate the contract of
ADJUST-ARRAY in copying the array. This can be tedious and may be error
prone. It would be better for such code to be written once, efficiently
and uniformly, and then offered to the user in a well-packaged way.
Conversion Cost:
No correct user code currently tries to modify arrays which are
non-adjustable, so this change is technically upward compatible.
Some advanced code-walking tools which believe that this function
works only by side-effect would have to be modified very slightly
to know that its return value was of interest.
Aesthetics:
I'm not sure how people's sense of aesthetics is affected by this.
Discussion:
MACSYMA needed something like this.
If people don't like this, I could construct an alternate variation of
this proposal which involved the introduction of a new COPY-ARRAY
primitive that took an input array and some combination of the args
now allowed by MAKE-ARRAY and ADJUST-ARRAY. The variation above seemed
the simplest to me, but the presence of a COPY-ARRAY such as described
in this paragraph would also have satisfied my needs.
∂22-Apr-87 2307 Moon@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Apr 87 23:07:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 122478; Thu 23-Apr-87 02:08:00 EDT
Date: Thu, 23 Apr 87 02:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Hornig@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870227172152.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870423020745.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Larry's status report says that this issue has been agreed, and that the
answer is 1c and 2c (in the terminology of the referenced message), that
is, the throw that invoked the unwind-protect is abandoned and the new
throw takes place, regardless of whether the target of the new throw is
dynamically inside or equal-to-or-outside-of the target of the original
throw.
I never agreed to this, and I think you are overlooking something. I
went back through the old discussion and couldn't find any discussion of
this issue: Consider the form
(loop
(catch 'foo
(unwind-protect (loop)
(throw 'foo t))))
With the proposed semantics, it is impossible to stop this program
except by hitting it with two throws in rapid succession, with exactly
the right amount of delay between them so that the catch and
unwind-protect have not yet been re-established when the second throw
strikes. Consider any program-stopping operation that aborts execution
by throwing to a catch in the top-level read-eval-print loop (control-G
in Maclisp or c-Abort in Genera; most other systems have their own
equivalent of this). With the proposed semantics, when this throw
executes the unwind-protect cleanup handler, as it must, the throw will
be abandoned and execution will resume looping.
To me, the inability to stop a program is a much worse problem than
providing so-called correct semantics for a contrived program that
doesn't correspond to any real application. It was suggested that the
error system might depend on the ability to abort throws like this. If
that were demonstrated, I would change my tune, but until it's
demonstrated I am completely skeptical of the notion that any error
system would do this.
Therefore I propose that case 1, transfer to a point inside the point to
which control would have transferred, not do the second throw. There
are two things we could require it to do instead (or we could just
wimping out and say it "is an error"). It could signal an error, or
it could resume the original throw, just as if the cleanup handler had
exited normally. I prefer signalling an error, because I firmly believe
that the program is ill-formed. Note that signalling an error must
avoid the following pitfall once an error-handling facility is added to
Common Lisp:
(loop
(ignore-errors
(unwind-protect (loop)
(error))))
The illegal-nested-throw error must not be caught by ignore-errors or
nothing will have been solved.
At a minimum I would like to see these considerations included in the
discussion section of the issue file before it is released. Not all
readers of the file will immediately realize that option (1c) installs
a serious environment bug into Common Lisp.
∂23-Apr-87 1205 smith@nrl-aic.ARPA A simple question
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 12:05:27 PDT
Return-Path: <smith@nrl-aic.ARPA>
Received: Thu, 23 Apr 87 14:05:35 est by nrl-aic.ARPA id AA10064
Date: 23 Apr 1987 13:42:18 EST (Thu)
From: Russ Smith <smith@nrl-aic.ARPA>
Subject: A simple question
To: common-lisp@sail.stanford.edu
Cc: spears@nrl-aic.arpa
Message-Id: <546201738/smith@nrl-aic>
The "Cc"ed individual above uncovered an interesting difference between
interpreted and compiled CommonLisp on a Sun workstation that generated
a splurge of conversation here. In particular:
(null (null '(a b c))
returns T when interpreted, but returns (a b c) when compiled. On
reading the **Sun** CommonLisp manual, this behavior, while possibly
despicable, is permitted. On reading THE CommonLisp manual, things are
not quite as obvious. Page 73 contains a definition for NULL that may
or may not say that NULL returns strictly T or NIL (see also page 82).
What's the poop?
∂23-Apr-87 1250 Moon@STONY-BROOK.SCRC.Symbolics.COM A simple question
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 12:50:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123106; Thu 23-Apr-87 15:50:29 EDT
Date: Thu, 23 Apr 87 15:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A simple question
To: Russ Smith <smith@NRL-AIC.ARPA>
cc: common-lisp@sail.stanford.edu, spears@NRL-AIC.ARPA
In-Reply-To: <546201738/smith@nrl-aic>
Message-ID: <870423155015.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 23 Apr 1987 13:42:18 EST (Thu)
From: Russ Smith <smith@nrl-aic.ARPA>
The "Cc"ed individual above uncovered an interesting difference between
interpreted and compiled CommonLisp on a Sun workstation that generated
a splurge of conversation here. In particular:
(null (null '(a b c))
returns T when interpreted, but returns (a b c) when compiled.
My question for you: Does (not (null '(a b c)) do the same thing in the
same implementation, or does it always return T?
∂23-Apr-87 1255 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM A simple question
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 23 Apr 87 12:55:02 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79392; Thu 23-Apr-87 15:54:33 EDT
Date: Thu, 23 Apr 87 15:54 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: A simple question
To: Russ Smith <smith@NRL-AIC.ARPA>, common-lisp@sail.stanford.edu
cc: spears@NRL-AIC.ARPA
In-Reply-To: <546201738/smith@nrl-aic>
Message-ID: <870423155440.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: 23 Apr 1987 13:42:18 EST (Thu)
From: Russ Smith <smith@nrl-aic.ARPA>
Page 73 contains a definition for NULL that may
or may not say that NULL returns strictly T or NIL (see also page 82).
What's the poop?
Page 73 says several things. It says NULL returns true if the argument
is (). To me at least, this implies NULL is used for flow/predicate and
not for value. It goes on to say that NULL is the same as NOT. NOT
(page 82) explicitly says NOT returns T or NIL. It also says NULL is
the same as NOT. If you believe in transitive closure, one would
conclude that (null (null something)) returns strictly T or NIL. Poor
programs may be broken by this; better programs never use (null (null
...)) but instead express the better intent (not (null ...)).
Personally, I would consider (null (null ...)) to be "an error" and that
the compiler for the Sun should be able to get away with returning the
inner argument. Things get worse when you separate nil and ().
∂23-Apr-87 1313 REM@IMSSS Just for fun (NULL of NULL is identity)
Received: from IMSSS by SAIL with PUP; 23-Apr-87 13:13 PDT
Date: 23 Apr 1987 1310-PDT
From: Rem@IMSSS
Subject: Just for fun (NULL of NULL is identity)
To: COMMON-LISP@SU-AI
That "despicable" behaviour of NULL on the SUN when compiled,
namely that (NULL (NULL 'FOO)) returns FOO instead of T,
could have been obtained interpreted too if something like this
had been done:
(SETQ G*NON-NULL-VALUE 'T) ;Initial value
(DEFUN MY-NULL (LL)
(COND (LL (PROGN (SETQ G*NON-NULL-VALUE LL)
'NIL))
(T G*NON-NULL-VALUE)))
Does CLtL explicitly forbid this? I don't think so. It defines "true"
as anything not NIL, and says NULL is "true" if it argument is ().
But it *does* say that (null x) is the same as (eq x '()), so
presumably if you hack NULL then EQ must be hacked too, and
also typep.
-------
∂23-Apr-87 1822 RWK@YUKON.SCRC.Symbolics.COM A simple question
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 18:22:01 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198073; Thu 23-Apr-87 21:09:50 EDT
Date: Thu, 23 Apr 87 21:09 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: A simple question
To: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: Russ Smith <smith@NRL-AIC.ARPA>, common-lisp@sail.stanford.edu,
spears@NRL-AIC.ARPA
In-Reply-To: <870423155440.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Message-ID: <870423210941.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 23 Apr 87 15:54 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Page 73 says several things. It says NULL returns true if the argument
is (). To me at least, this implies NULL is used for flow/predicate and
not for value. It goes on to say that NULL is the same as NOT. NOT
(page 82) explicitly says NOT returns T or NIL. It also says NULL is
the same as NOT. If you believe in transitive closure, one would
conclude that (null (null something)) returns strictly T or NIL. Poor
programs may be broken by this; better programs never use (null (null
...)) but instead express the better intent (not (null ...)).
Personally, I would consider (null (null ...)) to be "an error" and that
the compiler for the Sun should be able to get away with returning the
inner argument. Things get worse when you separate nil and ().
I disagree; after all, NOT is the same as NULL.
(NOT (NULL <something)) has long been an idiom for
"always return T or NIL".
I'll bet the Sun compiler does the same thing for
(NOT (NULL <something>))?
∂23-Apr-87 1858 KMP@STONY-BROOK.SCRC.Symbolics.COM A simple question
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 18:58:27 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123583; Thu 23-Apr-87 21:57:24 EDT
Date: Thu, 23 Apr 87 21:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A simple question
To: smith@NRL-AIC.ARPA, spears@NRL-AIC.ARPA
cc: RWK@STONY-BROOK.SCRC.Symbolics.COM,
DCP@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SAIL.STANFORD.EDU
In-Reply-To: <870423210941.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870423215712.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Some miscellaneous observations on this issue...
In my opinion, it is not appropriate to document that NOT and NULL are the
same even if they have identical behavior. If their intended uses differ
(as I would claim they do), they are not interchangeable. Perhaps we can
get this wording fixed in the upcoming manual. People should use NULL for
lists and not for predicates as a matter of style. Although (NULL (NULL x))
is not "an error" in the CLtL sense, I'd put red marks next to it if I were
teaching a programming course and someone turned in a program that did it.
By the way, there are GC implications to returning the thing itself and not
T. If the x was a large structure that was not otherwise pointed to, it
would be a shame for it to not get GC'd just because someone was passing
it around for truth value.
Also, there are data abstraction issues. You run the risk of accidentally
violating the integrity of private data structures if you give them away,
and the compilers should be leary of optimizations that can do this kind
of thing.
In T (Yale Scheme), we actually created a whole line of operators called
MEMBER?, ASSOC?, etc. which were like MEMBER, ASSOC, etc. but returned
T/NIL for cases where abstraction and/or GC behavior was an issue.
On the LispM, this optimization would be particularly funny for stack lists
since I guess you could claim that a stack list could `rightly' be returned
here (it being non-null, after all, regardless of what its ever-varying
contents were). If you never used it for anything other than its existence
and non-nullness...
This optimization, by the way, is related to the (+ X 0) => X optimization,
which can be pretty bizarre error-checking-wise when X is a string or some
other non-addable quantity and SAFETY is high (because no error may get
signalled where the intuition may be that one should be). Presumably the
next CL standard should take some stand on optimizations like this so that
users can know what to expect (or know to expect nothing) and implementors
can know what to feel comfortable about providing.
∂23-Apr-87 2022 RWK@YUKON.SCRC.Symbolics.COM Streams
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 20:22:00 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198124; Thu 23-Apr-87 23:22:02 EDT
Date: Thu, 23 Apr 87 23:21 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Streams
To: James R. Rauen <rauen@CLS.LCS.MIT.EDU>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8704221755.AA00926@CLS.LCS.MIT.EDU>
Message-ID: <870423232136.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: 22 Apr 1987 1254-EST (Wednesday)
From: rauen@CLS.LCS.MIT.EDU (James R. Rauen)
I'm encountering some difficulties with synonym streams. Let's say I
do the following:
(defvar a *standard-input*)
(defvar b *standard-output*)
(defvar c (make-synonym-stream 'a))
(defvar d (make-synonym-stream 'b))
(defvar e (make-two-way-stream c d))
(setq a *standard-output*)
Now stream C has been turned into an output stream. What is E now?
Illegal. It's first argument is required to be an input stream.
What does it answer to INPUT-STREAM-P?
Probably T, in in many implementations. NIL if it
actually checks its input stream.
I can also cause trouble by
changing the value of a synonym stream's variable from a character
stream to a byte stream.
Sure. CL gives you enough rope to hang yourself.
∂23-Apr-87 2338 edsel!bhopal!jonl@navajo.stanford.edu A simple question
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 23:38:15 PDT
Received: by navajo.stanford.edu; Thu, 23 Apr 87 22:37:32 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA25848; Thu, 23 Apr 87 22:26:02 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA06964; Thu, 23 Apr 87 23:23:38 PDT
Date: Thu, 23 Apr 87 23:23:38 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704240623.AA06964@bhopal.edsel.com>
To: navajo!smith%nrl-aic.ARPA@navajo.stanford.edu
Cc: navajo!common-lisp%sail@navajo.stanford.edu,
navajo!spears%nrl-aic.arpa@navajo.stanford.edu
In-Reply-To: Russ Smith's message of 23 Apr 1987 13:42:18 EST (Thu)
Subject: A simple question
What is the version number of your Sun Common Lisp ? try calling
(lisp-implementation-version), or look at the initial greeting.
Version 2 (and it's follow-ons) has been current since December 1986,
and doesn't have the pessimization you reported, namely that
(not (not x)) ==> x. Version 1 appears to have the problem.
As has often been remarked, "The source of all bugs is pre-mature
optimization."
-- JonL --
∂24-Apr-87 0741 decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM Mailing List
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87 07:39:50 PDT
Received: from decvax.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA28946; Fri, 24 Apr 87 06:40:48 PST
Received: from admin.uucp (mcae) by cvbnet.uucp (2.0/SMI-2.0)
id AA02955; Fri, 24 Apr 87 10:16:40 est
Received: by admin.uucp (1.1/SMI-3.0DEV3)
id AA13156; Fri, 24 Apr 87 10:12:41 EST
Date: Fri, 24 Apr 87 10:12:41 EST
From: decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM (Ted Bardasz)
Message-Id: <8704241512.AA13156@admin.uucp>
To: cvbnet!decvax!decwrl!SAIL.STANFORD.EDU!COMMON-LISP@decwrl.DEC.COM
Subject: Mailing List
Hello,
Could you please add me to the mailing list for:
COMMON LISP
My mail address is:
decvax!cvbnet!basie!tbardasz@decwrl.dec.com
Thank you very much,
Ted Bardasz at Computervision Corp.
∂24-Apr-87 0752 smith@nrl-aic.ARPA Re: A simple question
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 24 Apr 87 07:52:09 PDT
Return-Path: <smith>
Received: Fri, 24 Apr 87 06:19:15 est by nrl-aic.ARPA id AA01286
Date: 24 Apr 1987 06:01:42 EST (Fri)
From: Russ Smith <smith@nrl-aic.ARPA>
Subject: Re: A simple question
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: spears@nrl-aic.arpa, common-lisp@sail.stanford.edu
Message-Id: <546260502/smith@nrl-aic>
In-Reply-To: David A. Moon's message of Thu, 23 Apr 87 1550 EDT
(not (null '(a b c)) returns the correct value (CLtL definition of
NOT, not Sun's...which, though apparently returning the correct value,
is not documented entirely correctly).
But this does not answer the question of what NULL is supposed to
return. The definition given on page 73 is arguably ambiguous. What
does "same operation" mean? Is this equivalence (one is just an alias
for the other)? Or is it merely a way of saying that the functionality is
somewhat similar as far as various interesting things are concerned?
Note, for example, that the TYPEP and EQ triple-line equivalences given
below the definition return true or false, not T or NIL.
I remain perplexed.
∂24-Apr-87 0843 DALY@IBM.COM CLtL typos list
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87 08:42:59 PDT
Date: 24 April 1987, 11:26:11 EDT
From: Timothy Daly <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <042487.112612.daly@ibm.com>
Subject: CLtL typos list
To those who have asked, yes there is a CLtL typos list.
The header on the file says the directory is:
/u/gis/tl/sla/corr.txt dated 12/6/85
My copy has been IBMeroxed through so many generations that it is
almost unreadable. From the GIS in the pathname I assume the
source is Guy Steele and I believe his tent is still pitched at CMU.
Guy, if you receive this, is there a later version?
Tim Daly
DALY@IBM.COM
∂24-Apr-87 2307 coffee@aerospace.aero.org Re: A simple question
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 24 Apr 87 23:07:25 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
id AA08928; Fri, 24 Apr 87 22:53:56 PST
Posted-Date: Fri, 24 Apr 87 22:53:47 -0800
Message-Id: <8704250653.AA08928@aerospace.aero.org>
To: Russ Smith <smith@nrl-aic.ARPA>
Cc: common-lisp@sail.stanford.edu
Subject: Re: A simple question
In-Reply-To: Your message of 23 Apr 1987 13:42:18 EST (Thu).
<546201738/smith@nrl-aic>
Date: Fri, 24 Apr 87 22:53:47 -0800
From: coffee@aerospace.aero.org
Page 71 of CLtL resolves any ambiguity on page 73 when it says, "We say that
a predicate is true when it returns a non-nil value, and is false when it
returns nil..."; thus <wry grin> implementors are free to let an expression
like (null (null 'foo)) return GRAND_PIANO if they wish, but portability-
oriented programmers are _not_ free to assume anything but non-nilness in
the returned value.
Personally, NUMBERP is the one that bothers me: it would be so nice to get
back the argument if it is numeric, nil otherwise, but CLtL merely says that
the value will be "true" and this is all that one may safely assume. Saying,
as CLtL does, that (numberp x) is identical (as in three horizontal bars) to
(typep x 'number) even tends to _suggest_ that the value _will_ be strictly
T or nil, a loss in my opinion.
Thanks for bringing this up--rationalization of this issue may be worth
fighting for in the ANSI Common Lisp committee's "clean-up of Steele" phase.
- Pc↑2
∂25-Apr-87 0052 VERACSD@A.ISI.EDU Pronunciation
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 25 Apr 87 00:51:48 PDT
Date: 24 Apr 1987 23:01-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Pronunciation
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: veracsd@A.ISI.EDU
Message-ID: <[A.ISI.EDU]24-Apr-87 23:01:01.VERACSD>
What is the proper pronunciation of PROG?
∂25-Apr-87 2132 @po5.andrew.cmu.edu:zs01#@andrew.cmu.edu Re: Pronunciation
Received: from PO5.ANDREW.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Apr 87 21:32:38 PDT
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA00915> for common-lisp@SAIL.STANFORD.EDU; Sun, 26 Apr 87 00:33:24 EDT
Received: via switchmail; Sun, 26 Apr 87 00:33:21 edt
Received: FROM z.itc.cmu.edu VIA queuemail
ID </cmu/common/mailqs/q007/QF.z.itc.cmu.edu.20918de2.40>;
Sun, 26 Apr 87 00:32:36 edt
Received: FROM z.itc.cmu.edu VIA qmail
ID </cmu/itc/zs01/.Outgoing/QF.z.itc.cmu.edu.20918d57.d57bad>;
Sun, 26 Apr 87 00:30:17 edt
Message-Id: <QUYMpKy00Vs8yuk0J8@andrew.cmu.edu>
X-Trace: MS Version 3.22 on ibm032 host z.itc.cmu.edu, by zs01 (623).
Date: Sun, 26 Apr 87 00:30:14 edt
From: zs01#@andrew.cmu.edu (Zalman Stern)
To: common-lisp@SAIL.STANFORD.EDU
Subject: Re: Pronunciation
Cc: veracsd@A.ISI.EDU
In-Reply-To: <[A.ISI.EDU]24-Apr-87 23:01:01.VERACSD>
>>>>What is the proper pronunciation of PROG?
Rhymes with "frog". And most code (with the exception of macro expansions)
that uses them should croak.
Sincerely,
Zalman Stern
∂25-Apr-87 2341 KMP@STONY-BROOK.SCRC.Symbolics.COM Pronunciation
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Apr 87 23:41:34 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 124696; Sun 26-Apr-87 02:41:53 EDT
Date: Sun, 26 Apr 87 02:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Pronunciation
To: zs01#@andrew.cmu.edu
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <QUYMpKy00Vs8yuk0J8@andrew.cmu.edu>
Message-ID: <870426024148.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Could we please terminate this discussion before it leads to a rush of
useless mail. I'm sure there are as many people who would suggest that
`the other' pronunciation is better. It doesn't matter who's right.
This mailing list reaches a huge number of people, many of whom are quite
busy. Also, many mailers get bogged down a long time delivering each
piece of mail sent. It's not worth the time spent either by the
mailers or by the readers of the mail to debate issues which have such
a large potential for going on forever, so little chance of being
usefully resolved, and so little value even if resolved.
∂27-Apr-87 1008 unido!gmdzi!LISPM-1.GMD!@lispm-1.gmd.jc Pronunciation
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 27 Apr 87 10:08:21 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA04143; Mon, 27 Apr 87 13:08:25 EDT
Received: by unido.uucp with uucp;
Mon, 27 Apr 87 18:03:36 +0100
Received: by gmdzi.UUCP id AA16067; Mon, 27 Apr 87 15:35:30 -0100
Date: Mon, 27 Apr 87 15:34+0100
From: "Juergen Christoffel" <unido!gmdzi!LISPM-1!JC@seismo.CSS.GOV>
Subject: Pronunciation
To: common-lisp@sail.stanford.edu
Cc: KMP@stony-brook.scrc.symbolics.com
In-Reply-To: <870426024148.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870427153401.6.JC@LISPM-1.GMD>
Date: Sun, 26 Apr 87 02:41 EDT
From: "Kent M Pitman" <KMP%STONY-BROOK.SCRC.Symbolics.COM%unido@gmdzi>
Could we please terminate this discussion before it leads to a rush of
useless mail. [...]
This mailing list reaches a huge number of people, many of whom are quite
busy. [...]
Kent, I agree. And, *please*, all of you listeners: when composing a
reply, think twice before yanking in the whole message which spawned
your reply. I don't need the original message that many times sent to
me; normally it should be sufficient, to quote a part of it. So,
please, stop this annoying habbit.
Thank you, JC
∂27-Apr-87 1110 Moon@STONY-BROOK.SCRC.Symbolics.COM MULTPLE-VALUE-OR &rest args
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Apr 87 11:09:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 125233; Mon 27-Apr-87 14:05:18 EDT
Date: Mon, 27 Apr 87 14:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MULTPLE-VALUE-OR &rest args
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 21 Apr 87 15:45 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET
Message-ID: <870427140455.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 21 Apr 87 15:45 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
>I don't think this conclusion follows from your previous paragraph.
>If the proposed MULTIPLE-VALUE-OR can easily be implemented in terms of
>existing primitives, such as MULTIPLE-VALUE-CALL, and would be efficient
>if there were non-consing &rest arguments, and non-consing &rest arguments
>are desirable for other reasons, then I think a more logical conclusion is
>"because non-consing &rest arguments can only be done efficiently by low-level
>implementation-specific code, they should be in Common Lisp."
Are you just pointing out a flaw in my logic, or are you suggesting that
Common Lisp REQUIRE certain &rest args to not cons?
I was suggesting that a declaration which, like all declarations,
encourages but does not require the compiler to generate a certain kind
of code, could be added to Common Lisp. If it were added, it would be
more broadly applicable than MULTIPLE-VALUE-OR, and would eliminate the
need for MULTIPLE-VALUE-OR as a special language construct since it
would make the portable definition of MULTIPLE-VALUE-OR efficient.
The last sentence
was not meant to logically follow from the previous -- I was merely
re-iterating my point in requesting a MULTIPLE-VALUE-OR form, which is it
can be efficiently implemented WITHOUT non-consing rest args. I might
also add that using MULTIPLE-VALUE-CALL is going to require both
a Lambda and a Block, in which the Return-From will end up being a Throw.
You are assuming that (multiple-value-call #'(lambda ...) ...) cannot be compiled
as efficiently as ((lambda ...) ...). I see no justification for assuming that.
∂27-Apr-87 1119 coffee@aerospace.aero.org Cleaning up predicate returns
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 27 Apr 87 11:18:48 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
id AA10100; Mon, 27 Apr 87 11:15:03 PDT
Posted-Date: Mon, 27 Apr 87 11:14:52 -0800
Message-Id: <8704271815.AA10100@aerospace.aero.org>
To: common-lisp@sail.stanford.edu
Cc: Masinter.pa@xerox.com
Subject: Cleaning up predicate returns
Date: Mon, 27 Apr 87 11:14:52 -0800
From: coffee@aerospace.aero.org
> From: Masinter.pa@xerox.com
> Subject: Re: A simple question
> To: coffee@aerospace.aero.org
> If this were to be "cleaned up", in which way should it go?
> Should NOT, NULL, EQ and friends be required to return T or NIL always,
> rather than the less-specified "true" and NIL? Would this adversely
> affect performance? Are there any current implementations which don't
> return T or NIL for predicates?
I haven't put together a complete clean-up proposal yet, part of which
would certainly be discussion of implementation costs (regarding which
I have a bit of research to do!).
We have to be able to take the type of a NIL, and to recognize NIL as a
symbol, etc., so we can't realistically have (for example) ATOM return
its argument if true and NIL otherwise.
With CONSP, NUMBERP, STRINGP, INTEGERP, and all of the other predicates on
CLtL 74-76 except LISTP & COMMONP, however, there's no ambiguity in returning
the argument if true and NIL otherwise. I have grown accustomed to this
behavior in the ExperTelligence Lisps, and have to remind myself when writing
code that I'll need to port that this "filter" view of a predicate (as
opposed to the traditional "Boolean" view) is not portable at this time. We
have certainly grown used to the filter treatment of AND and OR, so I don't
think we're Boolean bigots here, and requiring this would not break code
unless it does things like testing for EQness to T instead of just using the
returned value as the Boolean.
The only argument I can see for _requiring_ return of strictly T or NIL,
in these cases or in all of the currently indeterminate cases -- and
it may be a good argument at that -- is that it promotes portability by
preventing programmer reliance on a discretionary implementation that might,
for example, have LISTP return the object if it is a non-empty list and return
merely T for the empty list (nil otherwise). I don't favor this as standard
behavior, since LISTP could then return either a list or the T atom as
"true," meaning that code would need to check for each and be just
as ugly (or worse) than if return is limited (or assumed to be limited) to
T or NIL strictly.
I stress that this is a "wouldn't it be nice if," based on my own ideas of
what makes good-looking code, _not_ yet researched to the point that I call
it a "proposal." The extent to which I get flamed will probably determine
whether it dies immediately :-). I've run it past one other Lisper here
and been "Boolean bashed": he thought this style much less readable.
Of course, no one would _have_ to use the value as anything but a Boolean.
Regards, Pc↑2
∂27-Apr-87 1206 larus@paris.Berkeley.EDU (reduce #'or ...)
Received: from [128.32.150.46] by SAIL.STANFORD.EDU with TCP; 27 Apr 87 12:06:26 PDT
Received: by paris.Berkeley.EDU (3.2/1.22)
id AA22811; Mon, 27 Apr 87 12:06:56 PDT
From: larus@paris.Berkeley.EDU (James Larus)
Message-Id: <8704271906.AA22811@paris.Berkeley.EDU>
To: common-lisp@sail.stanford.edu
Subject: (reduce #'or ...)
Date: Mon, 27 Apr 87 12:06:52 PDT
I use REDUCE quite frequently and recently ran across a strange
interaction between it and another CL feature. I was trying to
execute:
(reduce #'or (mapcar ...))
The problem is that OR is a macro, not a function, so that the idiom
#'OR is disallowed by some (all?) Lisps. Even if the idiom was legal,
REDUCE could not funcall OR.
I can always define my own OR function, which is strict in both
arguments, but that does not really fix the problem. I doubt that I
am the first or last person to stumble across this interaction.
I'd like to suggest to the committee cleaning up CL that they try
unraveling the multiple semantics given to OR and AND. I think that
the language would be cleaner if logical operations were seperated
from control-flow.
/Jim
∂27-Apr-87 1338 quiroz@rochester.arpa Re: (reduce #'or ...)
Received: from CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 27 Apr 87 13:38:16 PDT
Received: by cayuga.cs.rochester.edu (5.52/a) id AA05810; Mon, 27 Apr 87 16:37:37 EDT
Received: from loopback by ur-seneca.arpa id AA08517 (4.12z); Mon, 27 Apr 87 16:37:26 edt
Message-Id: <8704272037.8517@ur-seneca.arpa>
To: larus@paris.Berkeley.EDU (James Larus)
Cc: common-lisp@sail.stanford.edu
Subject: Re: (reduce #'or ...)
In-Reply-To: Your message of Mon, 27 Apr 87 12:06:52 PDT.
<8704271906.AA22811@paris.Berkeley.EDU>
Date: Mon, 27 Apr 87 16:37:18 -0500
From: quiroz@rochester.arpa
I agree it is a bad surprise to rediscover that OR is not a
function, it happens to me rather often.
These days I rely on things like:
(some #'<predicate> <sequence>)
whenever I feel like doing
(reduce #'or (mapcar #'<predicate> <sequence>))
I hope that is more or less what you need. (The <predicate>s need
not be the same, needless is to say the example above is not a
mechanical equivalence.)
=Cesar
--------
Cesar Augusto Quiroz Gonzalez
Department of Computer Science {allegra|seismo}!rochester!quiroz
University of Rochester or
Rochester, NY 14627 quiroz@cs.rochester.edu
∂27-Apr-87 1340 coffee@aerospace.aero.org Very BIG "T"
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 27 Apr 87 13:39:39 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
id AA11832; Mon, 27 Apr 87 13:31:39 PDT
Posted-Date: Mon, 27 Apr 87 13:31:34 -0800
Message-Id: <8704272031.AA11832@aerospace.aero.org>
To: common-lisp@sail.stanford.edu
Subject: Very BIG "T"
Date: Mon, 27 Apr 87 13:31:34 -0800
From: coffee@aerospace.aero.org
> The only argument I can see for _requiring_ return of strictly T or NIL...
> is that it promotes portability...
Excuse me -- I missed the earlier message that observes how unpleasant
it would be to keep a big, otherwise unused object around merely because
it's being passed around as the non-NIL returned from a predicate. Good
point.
- Pc↑2
∂27-Apr-87 1517 Mailer@XX.LCS.MIT.EDU (reduce #'or ...)
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Apr 87 15:17:43 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 27 Apr 87 18:15-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 40029; 27 Apr 87 18:15:41-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 34140; 27 Apr 87 16:44:00-EDT
Date: Mon, 27 Apr 87 16:45 EDT
From: Don Morrison <dfm@JASPER.PALLADIAN.COM>
Subject: (reduce #'or ...)
To: larus@paris.Berkeley.EDU
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8704271906.AA22811@paris.Berkeley.EDU>
Message-ID: <870427164540.5.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>
Date: Mon, 27 Apr 87 12:06:52 PDT
From: larus@paris.Berkeley.EDU (James Larus)
I use REDUCE quite frequently and recently ran across a strange
interaction between it and another CL feature. I was trying to
execute:
(reduce #'or (mapcar ...))
Will using "some" solve your problems? I believe that (some #'f L) is equivalent to
(reduce #'(lambda (x y) (or x y)) (mapcar #'f L) :initial-value nil), except that in most implementations it's faster and
conses less, so long as f doesn't have side effects.
The fact that and and or only evaluate as many of their arguments as necessary is hardwired into most LISPers spines,
and many believe that using it as a control construct is often more perspicuous than the alternatives. I think it most
unlikely that it'll be changed.
∂28-Apr-87 2212 MURRAY%cs.umass.edu@RELAY.CS.NET MULTIPLE-VALUES OR
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 28 Apr 87 22:12:17 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac13332; 29 Apr 87 1:05 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ac04612; 29 Apr 87 1:02 EDT
Date: Tue, 28 Apr 87 08:50 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SAIL.STANFORD.EDU
Subject: MULTIPLE-VALUES OR
X-VMS-To: CLMAIL
The idea behind Multiple Values is that they are more efficient and
cleaner than the basic alternatives of returning a list, or stashing
values in global variables.
If using Multiple Values is going to be more costly than
these alternatives, then their use will not be widespread.
I think they have suceeded in this regard, and believe they will become more
common at time goes on. However, I think MULTIPLE-VALUE-OR is a case
where it fails to live up to its efficiency goals.
I have written code that needed OR which returned multiple values, (and after
spending a while tracking down a strange bug that ending up being OR not
returning multiple values except if its the LAST form), I wrote it as a macro.
I have since changed the code to store the results in global variables
because it made the function much faster, and speed was important for this
particular function.
I would like to think Common Lisp implementors will provide non-consing
&Rest args, since they are very useful for many things, as their use
on the MIT-based Lisp Machines shows, but it is not a trivial task.
MULTIPLE-VALUE-OR can be implemented without them (I'll give details
if anyone really wants to know), but perhaps MULTIPLE-VALUE-OR just isn't that
widely applicable to warrant special treatment to make it as efficient
as possible. If people are happy with that, then I can live with
using uglier mechanisms when speed and efficiency are important.
- Kelly
∂28-Apr-87 2240 MURRAY%cs.umass.edu@RELAY.CS.NET (REDUCE #'OVERHEAD (MAP ...))
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 28 Apr 87 22:39:47 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac13592; 29 Apr 87 1:28 EDT
Received: from cs.umass.edu by RELAY.CS.NET id cf04612; 29 Apr 87 1:22 EDT
Date: Tue, 28 Apr 87 19:32 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SAIL.STANFORD.EDU
Subject: (REDUCE #'OVERHEAD (MAP ...))
X-VMS-To: CLMAIL
> From: James Larus <larus@paris.berkeley.edu>
> I use REDUCE quite frequently and recently ran across a strange
> interaction between it and another CL feature. I was trying to
> execute:
> (reduce #'or (mapcar ...))
If you're doing a lot of stuff like this, maybe you should look into
the "Generic Mapping Functions" that Daniel Corkill has defined.
They do much of what REDUCE + MAP is used for, but
the notion of combining the results of mapping is generalized,
and is done more efficiently since it isn't always necessary to cons
up the intermediate results.
MAPCAR can be thought of as using CONS to combine mapping results.
The above use of OR is generally done through SOME in Common Lisp, but
is expressed using the Generalized Maps as MAPC-OR. EVERY is MAPC-AND, and
MAPCAN (MAPC-NCONC) functionality is done better as MAPC-CONDCONS.
MAPC-MAX is a popular one, as is MAPC-+ (MAPC-UNION, MAPC-AVERAGE, etc).
There are also MAPL-xxx functions that operate on sucessive sublists.
We have plans to extend these to work on sequences and not just lists,
but haven't done it yet (:- of course, they handle circular-lists :-)
The MAP-FUN general form takes a gob of keywords
to allow just about any mapping combination to be defined, and all the
others are defined in terms of it. They are Functions, but have
Compiler transforms that convert them into very efficient DO loops.
We can probably get the code to anyone interested.
- Kelly Murray
University of Massachusetts
∂29-Apr-87 1407 gls@Think.COM CLtL typos list
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 14:07:06 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 29 Apr 87 13:48:47 EDT
Date: Wed, 29 Apr 87 13:45 EDT
From: Guy Steele <gls@Think.COM>
Subject: CLtL typos list
To: DALY@ibm.com, common-lisp@sail.stanford.edu
In-Reply-To: <042487.112612.daly@ibm.com>
Message-Id: <870429134554.3.GLS@BOETHIUS.THINK.COM>
Date: 24 April 1987, 11:26:11 EDT
From: Timothy Daly <DALY@ibm.com>
To those who have asked, yes there is a CLtL typos list.
The header on the file says the directory is:
/u/gis/tl/sla/corr.txt dated 12/6/85
My copy has been IBMeroxed through so many generations that it is
almost unreadable. From the GIS in the pathname I assume the
source is Guy Steele and I believe his tent is still pitched at CMU.
Guy, if you receive this, is there a later version?
Tim Daly
DALY@IBM.COM
Yes, there is a typos list, but the version of 12/6/85 is the latest one.
For everyone's information, I have not been at CMU for over four years,
and have not been in Pittsburgh for over two years (though I do love to
visit as often as I can). For those who care:
August 1980-December 1982 Assistant Professor, Carnegie-Mellon University
January 1983-January 1985 Senior Scientist, Tartan Laboratories
Assistant professor on leave, CMU
January 1985-present Thinking Machines Corporation, Cambridge, MA
--Guy
∂30-Apr-87 1113 @ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU (REDUCE #'OVERHEAD (MAP ...))
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 11:13:10 PDT
Received: from CASHEW.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 11948; Thu 30-Apr-87 14:00:56 EDT
Date: Thu, 30 Apr 87 14:00 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: (REDUCE #'OVERHEAD (MAP ...))
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU, miller@ACORN.CS.ROCHESTER.EDU
In-Reply-To: <8704290611.AA12297@cayuga.cs.rochester.edu>
Message-ID: <870430140059.2.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Date: Tue, 28 Apr 87 19:32 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
I'd like to see more on this, if possible...
Code/doc, etc.. I use MAP, MAPCAR, etc. a >lot<.
Brad Miller
------
miller@cs.rochester.edu
miller@acorn.cs.rochester.edu
miller@rochester.arpa
∂30-Apr-87 1355 FAHLMAN@C.CS.CMU.EDU Notice on Kyoto Common Lisp distribution
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 13:55:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 30 Apr 87 16:56:31-EDT
Date: Thu, 30 Apr 1987 16:56 EDT
Message-ID: <FAHLMAN.12298714494.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Notice on Kyoto Common Lisp distribution
Mr. Yuasa asked me to pass the following announcement along to the
appropriate mailing lists in the U.S.:
---------------------------------------------------------------------------
We, the Kyoto Common Lisp people have decided to distribute KCL
through channels other than a commercial company,
free of charge out of Japan.
We are looking for a best possible channel but it may take some time.
Please note the following:
1. We always claimed that no fee is charged for the source of KCL, and
if any fee is charged, it is exclusively for the service of distribution,
maintenance, etc. of the software.
2. We never received any kind of royality out of the software or service for
it up to present.
Research Institute for Mathematical Sciences
Kyoto University
Reiji Nakajima
Taiichi Yuasa
Masami Hagiya
∂01-May-87 1440 EMAILDEV%UKACRL.BITNET@BERKELEY.EDU Notice on Kyoto Common Lisp distribution
Received: from JADE.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 02:30:08 PDT
Received: by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.13)
id AA27974; Fri, 1 May 87 02:17:44 PDT
Message-Id: <8705010917.AA27974@jade.berkeley.edu>
Return-Path: EMAILDEV%UKACRL.BITNET@WISCVM.WISC.EDU
Received: By UK.AC.RL.IB (MAILER) ; Fri, 01 May 87 10:28:41 BST
Via: UK.AC.BHAM.COMP-V1; 1 MAY 87 10:28:37 BST
Date: 1-MAY-1987 10:25:30
From: BATTEN%UK.AC.BHAM.COMP-V1@ac.uk
To: COMMON-LISP@sail.stanford.edu
Subject: Notice on Kyoto Common Lisp distribution
Reply-To: Batten%bham.ac.uk@seismo.css.gov
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
Perhaps KCL could be distributed through the GNU project? I think it
needs a full common lisp.
ian
∂05-May-87 1825 FAHLMAN@C.CS.CMU.EDU Kyoto Common Lisp addendum
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 May 87 18:25:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 5 May 87 21:24:59-EDT
Date: Tue, 5 May 1987 21:24 EDT
Message-ID: <FAHLMAN.12300074083.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SAIL.STANFORD.EDU, AIList@STRIPE.SRI.COM
Subject: Kyoto Common Lisp addendum
A clarification from Mr. Yuasa:
To whom it may concern,
It seems that the previous note of ours, announcing that we are looking
for a free channel for KCL distribution, may have brought confusions and
misunderstandings to many people. It may be mostly because only the
facts were mentioned, with no explanation of the background necessary to
understand our intention.
Our intention is to make it clear that KCL is an academic free software.
By "free", we mean that any one can get it free of charge, if he agrees
the conditions we put in the License Agreement. It does NOT mean that
anyone has any *free*dom for KCL. In particular, we have no intention
to put KCL into the public domain. We would rather like to keep the
identity of KCL, so that we can keep up its high quality.
Some commercial organizations are now distributing KCL and they charge a
certain amount of fees to their customers. These fees are exclusively
for the distribution costs and the service they offer to their
customers. We require no royalties to them. We are happy if more
people have got the chance to use this software. It is a voluntary work
if we give them technical help on their requests.
Unfortunately, some people believe that we are receiving royalties for
KCL. In order to overcome this wrong belief, we decided to look for a
free channel for KCL distribution. Apparently, some KCL users
(including potential users) do not need any maintenance service at all.
We are glad to make KCL available to such users for free. Note that we
do not intend to restrict the activities of commercial organizations for
KCL distribution. We intend to give a choice to the user and to make it
clear what the user is charged for by commercial organizations. Note
also that some KCL versions require additional programs developed by
commercial organizations and we cannot force them to make their code
open to the public, though we expect them to do so.
We are now seriously looking for a free channel. We already found some
candidates, but it will take some time before we decide the best
appropriate channel for our purpose. In case we cannot find an
appropriate channel, we ourselves will directly distribute KCL.
However, this will require a lot of work and we will have to spend a lot
of time. So, this should be the last solution.
Thanks.
Taiichi Yuasa, Dr.
Research Institute for Mathematical Sciences
Kyoto University
∂08-May-87 1725 kempf%hplabsc@hplabs.HP.COM Rule System in CommonLoops/CLOS
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 8 May 87 17:24:53 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Fri, 8 May 87 16:25:43 pdt
Received: by hplabsc ; Fri, 8 May 87 16:26:06 pdt
Date: Fri, 8 May 87 16:26:06 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8705082326.AA15913@hplabsc>
To: common-lisp@sail.stanford.edu
Subject: Rule System in CommonLoops/CLOS
Anybody out there doing a rule system in CommonLoops or CLOS? There
is some interest here in such, if it is publically available. Thanks.
Jim Kempf kempf@hplabs.hp.com
∂09-May-87 0501 TMB%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Smalltalk-80 Classes for Symbolics and/or CommonLisp
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 May 87 05:00:52 PDT
Date: Sat 9 May 87 07:49:55-EDT
From: "Thomas M. Breuel" <TMB%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Smalltalk-80 Classes for Symbolics and/or CommonLisp
To: pcl-hackers%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
common-lisp%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
info-lispm%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
lisp-forum%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: tmb%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Message-ID: <12300974291.86.TMB@OZ.AI.MIT.EDU>
I am looking for an implementation of the Smalltalk-80 classes, or a
subset of them, on the Symbolics 3600 and/or under Common Lisp. I am
only interested in this for new program developments, not porting, so
compatibility is not a strict requirement. Implementations using
flavours or PCL are fine. If you have such a beast, or a pointer to
one, please let me know.
Thomas.
tmb@prep.ai.mit.edu
-------
∂12-May-87 0301 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU atom type question
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87 03:01:02 PDT
Received: from DESCARTES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 39231; Tue 12-May-87 06:00:35 EDT
Date: Tue, 12 May 87 06:00 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: atom type question
To: common-lisp@sail.stanford.edu
Message-ID: <870512060032.8.CFRY@DESCARTES.AI.MIT.EDU>
CLtL says, p. 73 "The predicate ATOM is true if its argument
is not a cons."
Is ATOM supposed to be true of non-COMMON data types as well?
∂12-May-87 0637 FAHLMAN@C.CS.CMU.EDU atom type question
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87 06:36:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 12 May 87 09:36:19-EDT
Date: Tue, 12 May 1987 09:36 EDT
Message-ID: <FAHLMAN.12301780077.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: atom type question
In-reply-to: Msg of 12 May 1987 06:00-EDT from Christopher Fry <cfry at OZ.AI.MIT.EDU>
CLtL says, p. 73 "The predicate ATOM is true if its argument
is not a cons."
Is ATOM supposed to be true of non-COMMON data types as well?
My opinion: unless the non-Common data type is a subtype of CONS, ATOM
should be true of it.
-- Scott
∂12-May-87 0715 RAM@C.CS.CMU.EDU atom type question
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87 07:06:37 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 12 May 87 10:05:57-EDT
Date: Tue, 12 May 1987 10:05 EDT
Message-ID: <RAM.12301785477.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: common-lisp@SAIL.STANFORD.EDU
Subject: atom type question
Date: Tuesday, 12 May 1987 06:00-EDT
From: Christopher Fry <cfry at OZ.AI.MIT.EDU>
Re: atom type question
...
Is ATOM supposed to be true of non-COMMON data types as well?
I think the language in the manual pretty clearly indicates that the
answer is yes, although there currently isn't much discussion of
extensions to the type system. CONS is a subtype of COMMON and ATOM =
(NOT CONS), therefore anything not COMMON must be an ATOM.
In can't see any reason for wanting thing to be otherwise. If you
want to add some new object that acts like a cons but isn't, then you
can make it a subtype of cons. Although CLTL says that
"implementations may not unilaterally add subtypes to COMMON", I think
that there is no way for a correct program to tell that you have added
a subtype except in the cases where CLTL says that some types form an
exhaustive partition of another type.
Rob
∂12-May-87 1753 RWK@YUKON.SCRC.Symbolics.COM atom type question
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87 17:52:41 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 207069; Tue 12-May-87 20:50:54 EDT
Date: Tue, 12 May 87 20:50 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: atom type question
To: Ram@C.CS.CMU.EDU
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12301785477.BABYL@>
Message-ID: <870512205052.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Tue, 12 May 1987 10:05 EDT
From: Ram@C.CS.CMU.EDU
Date: Tuesday, 12 May 1987 06:00-EDT
From: Christopher Fry <cfry at OZ.AI.MIT.EDU>
...
Is ATOM supposed to be true of non-COMMON data types as well?
I think the language in the manual pretty clearly indicates that the
answer is yes, although there currently isn't much discussion of
extensions to the type system. CONS is a subtype of COMMON and ATOM =
(NOT CONS), therefore anything not COMMON must be an ATOM.
In can't see any reason for wanting thing to be otherwise. If you
want to add some new object that acts like a cons but isn't, then you
can make it a subtype of cons.
I agree with this, except I don't believe in the type
COMMON. You can get the same result by omitting references
to COMMON: If it's not a subtype of CONS, by ATOM = (NOT CONS),
it must be an ATOM.
Although CLTL says that
"implementations may not unilaterally add subtypes to COMMON", I think
that there is no way for a correct program to tell that you have added
a subtype except in the cases where CLTL says that some types form an
exhaustive partition of another type.
Not even then, because you may be partitioning an one of those
types further, or extending one to contain additional elements.
COMMON is a joke. Without any clear statement of just what
COMMONP is supposed to buy you, it's impossible to come up
with any clear view of what it should mean. What happens
if Common Lisp '89 comes out, and defines 6 new types? Without
any advance knowledge of how this extension would be handled,
you can't write you code defensively using COMMON.
Instead, in situations where you try to handle all of the
types in CL, I believe you should just use ETYPECASE naming the
types you actually DO handle. Extended types will either fit
in with types you implemented (say a new subtype of CONS will
fit in with your LIST clause), or they won't.
∂13-May-87 1426 berman@vaxa.isi.edu &REST
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 13 May 87 14:26:22 PDT
Received: by vaxa.isi.edu (4.12/4.7)
id AA02845; Wed, 13 May 87 14:24:38 pdt
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8705132124.AA02845@vaxa.isi.edu>
Date: 13 May 1987 1424-PDT (Wednesday)
To: common-lisp@sail.stanford.edu
Cc: berman@vaxa.isi.edu
Subject: &REST
Now, I'm SURE this one has come up, but here goes...
In your favorite implementation of CL, try this:
(DEFUN FOO (&REST A) A)
(FOO 1 2 3)
By direct experience, both TI (version 2) and Symbolics (Version 7) do not
return (1 2 3). They have an efficiency hack wherein the cons space used to
create the &REST arg is reused, and thus the pointer that is returned (which
is a pointer to a list) is pointing to memory which does not contain the same
thing as when the pointer was last evaluated. That is, he process of
returning has the side effect of changing the contents of the list created
when binding A. Seth Goldman tells me that several Macintosh Lisps also
behave this way.
CLtL, on page 61, states:
"If there is a rest parameter, it is bound to a list of all as-yet-unprocessed
arguments."
This part works fine. These implementations DO make a list and bind it and
all that. The symbolics manual specifically warns one to use copylist if you
want to return any tail or sublist of an &REST argument (thus consing it in
"real" memory).
As I am putting together the test suite, I have run into a problem: Many
tests actualy use &REST. These seem to expect to get a proper list and not
some imaginary list that changes when the function returns. My feelings are
that the above efficiency hack is a bug, even though it may be "supported by
hardware".
Can anyone show me a valid justification for the above behavior? So far, HP
has an implementation that does the correct thing (returns the list). TI, in
their version 3 software (which we are beta-ing) has fixed this. Note that
page 60 clearly states, about the body in a lambda,
"The body consists of any number of forms (possibly zero). These forms are
evaluated in sequence, and the results of the last form only are returned as
the results of the application..."
This does not allow for any alteration of the results of the last form.
OK?
RB
∂13-May-87 1512 DLW@ALDERAAN.SCRC.Symbolics.COM &REST
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 13 May 87 15:12:26 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 81313; Wed 13-May-87 18:10:48 EDT
Date: Wed, 13 May 87 18:10 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: &REST
To: berman@vaxa.isi.edu, common-lisp@sail.stanford.edu
In-Reply-To: <8705132124.AA02845@vaxa.isi.edu>
Message-ID: <870513181032.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 13 May 1987 1424-PDT (Wednesday)
From: berman@vaxa.isi.edu (Richard Berman)
My feelings are
that the above efficiency hack is a bug, even though it may be "supported by
hardware".
Can anyone show me a valid justification for the above behavior?
There isn't any justification. It's a bug. It's among the list of
documented non-conformances of the Symbolics implementation, most of
which are a whole lot less severe than this one. Unfortunately, it is
extremely difficult to fix without an unacceptable impairment of
performance in this implementation. "No excuse, sir."
∂14-May-87 0913 coffee@aerospace.aero.org Re: &REST
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 14 May 87 09:12:30 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
id AA06471; Thu, 14 May 87 09:10:19 PDT
Posted-Date: Thu, 14 May 87 09:10:07 -0800
Message-Id: <8705141610.AA06471@aerospace.aero.org>
To: berman@vaxa.isi.edu (Richard Berman)
Cc: common-lisp@sail.stanford.edu
Subject: Re: &REST
In-Reply-To: Your message of 13 May 1987 1424-PDT (Wednesday).
<8705132124.AA02845@vaxa.isi.edu>
Date: Thu, 14 May 87 09:10:07 -0800
From: coffee@aerospace.aero.org
Well, I don't know about "several of the Macintosh Lisps," but ExperCommon
Release 2.2 handles (defun foo (&rest a) a);(foo 1 2 3) --> (1 2 3)
correctly; so, for that matter, do Gold Hill's GC286 and GC386(Hummingboard)
implementations. By the way, I've mentioned this in lisp news already, but
watch out for the Hummingboard Lisp: it thinks that log of 1e6 to the base
10 is a double-precision value slightly greater than pi, reproducibly, and
the rest of its math functions are similarly creative. It also gives
incorrect results (not error _messages_, mind you, just wrong answers)
running a version of Forgy's OPS5 that was only modified as necessary to
make it run on GC286. Gold Hill's phone support has been courteous and
sincerely interested, but for the moment we're in the incongruous position
of using the Hummingboard as an unbelievably nice editor but doing serious
testing and production on a plain-vanilla DeskPro 286...
∂14-May-87 1107 berman@vaxa.isi.edu Re: &REST
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 11:07:44 PDT
Posted-Date: Thu, 14 May 87 11:04:37 PDT
Message-Id: <8705141804.AA05984@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA05984; Thu, 14 May 87 11:04:45 PDT
To: coffee@aerospace.aero.org
Cc: berman@vaxa.isi.edu (Richard Berman), common-lisp@sail.stanford.edu
Subject: Re: &REST
In-Reply-To: Your message of Thu, 14 May 87 09:10:07 -0800.
<8705141610.AA06471@aerospace.aero.org>
Date: Thu, 14 May 87 11:04:37 PDT
From: berman@vaxa.isi.edu
Well, as for the "several Mac lisps", as I mentioned in my message this was
told to me by Seth goldman and was not a matter of my personal experience. I
did not name any names. He said ExperLisp DID behave incorrectly, but he
didn't say which release. I am glad to hear that it is not as widespread as
Seth implied.
RB
∂14-May-87 1314 coffee@aerospace.aero.org Re: Gold Hill's floating-point
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 14 May 87 13:13:52 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
id AA12386; Thu, 14 May 87 13:04:07 PDT
Posted-Date: Thu, 14 May 87 13:04:02 -0800
Message-Id: <8705142004.AA12386@aerospace.aero.org>
To: samalone@athena.mit.edu
Cc: common-lisp@sail.stanford.edu
Subject: Re: Gold Hill's floating-point
In-Reply-To: Your message of Thu, 14 May 87 13:37:25 EDT.
<8705141737.AA19398@HADES.MIT.EDU>
Date: Thu, 14 May 87 13:04:02 -0800
From: coffee@aerospace.aero.org
Thanks -- this explains an annoying, but different, problem that also
occurs under GC286 on an 80286/80287 machine. Thanks again (I'll put this
into my definition of the (dos) function to make it automatic).
- Peter C.
∂14-May-87 1438 berman@vaxa.isi.edu documentation
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 14:38:47 PDT
Posted-Date: Thu, 14 May 87 14:37:03 PDT
Message-Id: <8705142137.AA11169@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA11169; Thu, 14 May 87 14:37:05 PDT
To: common-lisp@sail.stanford.edu
Subject: documentation
Date: Thu, 14 May 87 14:37:03 PDT
From: berman@vaxa.isi.edu
What should the following do?
(documentation 'doc 'doc)
Per page 440 of CLtL, there is a list of documentation types, but no mention
of what to do if given some other symbol. Should it return NIL? Should it
signal or "be" an error? Can it return some other arbitrary value, or is it
totally up to the implementor?
Likewise, (setf (documentation 'doc 'doc) "xyz"),
I have an implementation here that allows documentation to work this way. It
appears to more or less syntactic-sugar for property lists, 'cuz in the above
case, the setf will put "xyz" on the symbol DOC as it documentation type DOC.
I have another implementation which is strictly by the book in that if it is
not on that list of legal documentation types, it signals an error.
Note: The first implementation is a bit too relaxed--it allows (setf
(documentation "FOO" 'doc) "xyz"), which is clearly incorrect 'cuz "Both
arguments must be symbols".
RB
∂14-May-87 1507 edsel!bhopal!jonl@navajo.stanford.edu Re: &REST
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 15:07:28 PDT
Received: by navajo.stanford.edu; Thu, 14 May 87 15:04:56 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA04439; Thu, 14 May 87 14:18:04 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA04811; Thu, 14 May 87 14:19:29 PDT
Date: Thu, 14 May 87 14:19:29 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705142119.AA04811@bhopal.edsel.uucp>
To: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu
Subject: Re: &REST
For compatibility with the semantics of CLtL, Lucid chose to make the
&rest arg be a true (heap-consed) list.
But the kinds of folks who have tolerated the bug which Dan Wienreb so
gloriously announced are not entirely stupid. There is a market, at
least amongst some systems programmers who use lisp, to get the kind of
"last-bit tweaking" performance that a stack-allocated &rest list would
afford. Lucid's product will shortly be giving the user access to some
of the underlying primitives which permit dynamic-extent consing (the
3600's "stack list" consing is one such example).
The default for &REST lists will, of course, still be lists of indefinite
extent.
-- JonL --
∂14-May-87 1724 FAHLMAN@C.CS.CMU.EDU documentation
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 17:24:38 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 14 May 87 20:23:56-EDT
Date: Thu, 14 May 1987 20:23 EDT
Message-ID: <FAHLMAN.12302422265.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: berman@VAXA.ISI.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: documentation
In-reply-to: Msg of 14 May 1987 17:37-EDT from berman at vaxa.isi.edu
I think that only the specified symbols are required to work. Anything
else "is an error". However, it is legal to extend the language so that
other symbols or even non-symbols work.
-- Scott
∂15-May-87 1035 coffee@aerospace.aero.org Re: Gold Hill's floating-point
Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 15 May 87 10:34:31 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
id AA01230; Fri, 15 May 87 10:29:47 PDT
Posted-Date: Fri, 15 May 87 10:29:32 -0800
Message-Id: <8705151729.AA01230@aerospace.aero.org>
To: MATHIS@ada20.isi.edu
Cc: common-lisp@sail.stanford.edu
Subject: Re: Gold Hill's floating-point
In-Reply-To: Your message of 15 May 1987 06:35-PDT.
<[ADA20.ISI.EDU]15-May-87 06:35:47.MATHIS>
Date: Fri, 15 May 87 10:29:32 -0800
From: coffee@aerospace.aero.org
Bob Mathis notes, correctly, that my earlier reply to samalone assumed
that you had all seen the original message. Mea culpa. The problem that
_he_ had fixed was Gold Hill 286's habit of returning _weird_-looking
floating-point results (multiple decimal points, etc.) after a period
of use: apparently, this is due to pushing to DOS and leaving the 8087
or 80287 in an odd state that Gold Hill's interpreter does not correct
on returning. The fix is to make the call (SYS::8087-FPP) after returning
from DOS. I have my own (dos) function defined in USERINIT to provide
a "press a key to return to Lisp" prompt if (dos) is called with an argument,
so adding this call to that function has fixed the problem.
The Hummingboard release uses the call (SYS::8087-FPP :emulate) in view
of the absence of a physical numeric chip on that board, and I have seen
no such bizarre behavior -- not this specific variety, I mean -- on it,
so there is no apparent reason to do this on the Hummer. The general problem
of floating-point creativity in GC 386 Developer continues, I'm sad to
say: how about (log 1024 2) --> 9.53638... to double precision? The same
result also occurs with single- or double-precision real arguments. Further,
another user tells me that regular old non-Hummingboard GC386 does the
same thing on her "Inboard" 386 card.
BTW, I have mentioned the substantial enhancements to the editor as a major
advantage of the Gold Hill 386 vs. 286 products; I learned yesterday that
a new, compiled, enhanced editor (sounds exactly like the 386 version) is a
key feature of the GC286 2.2 upgrade, $90. Since we're not seeing nearly the
factor of five speed increase that Gold Hill claims versus "an AT" (maybe
they ran against a 6 MHz machine? We're seeing speed ratios of from one to
four with a Hummingboard in a DeskPro 386 against an 8-MHz DeskPro 286),
consider this in your cost-effectiveness evaluation. A twelve- or sixteen-MHz
80286 with adequate RAM may be quite competitive, especially if (like us)
you're doing pattern recognition in telemetry streams or other number-
crunching things. Of course, the Hummingboard can be dropped right into any
XT clone with a decent hard disk, an important factor if you already
own such a box.
I'm sorry if this extended discussion of microcomputer implementations has
annoyed anyone: in general, I direct such comments to lang.lisp, and will
continue to do so now that the loose ends on this exchange are (I believe)
tied off. I would also like to stress that Gold Hill's people have been
prompt, courteous, and helpful in our discussions of these problems and that
I have every confidence that they will be quickly resolved.
Regards, Pc↑2
∂15-May-87 1331 @ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU (REDUCE #'OVERHEAD (MAP ...))
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87 13:31:40 PDT
Received: from CASHEW.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 12731; Fri 15-May-87 16:19:08 EDT
Date: Fri, 15 May 87 04:16 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: (REDUCE #'OVERHEAD (MAP ...))
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU, miller@ACORN.CS.ROCHESTER.EDU
In-Reply-To: <8704290611.AA12297@cayuga.cs.rochester.edu>
Message-ID: <870515041614.4.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Date: Tue, 28 Apr 87 19:32 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
> From: James Larus <larus@paris.berkeley.edu>
> I use REDUCE quite frequently and recently ran across a strange
> interaction between it and another CL feature. I was trying to
> execute:
> (reduce #'or (mapcar ...))
If you're doing a lot of stuff like this, maybe you should look into
the "Generic Mapping Functions" that Daniel Corkill has defined.
They do much of what REDUCE + MAP is used for, but
the notion of combining the results of mapping is generalized,
and is done more efficiently since it isn't always necessary to cons
up the intermediate results.
MAPCAR can be thought of as using CONS to combine mapping results.
The above use of OR is generally done through SOME in Common Lisp, but
is expressed using the Generalized Maps as MAPC-OR. EVERY is MAPC-AND, and
MAPCAN (MAPC-NCONC) functionality is done better as MAPC-CONDCONS.
MAPC-MAX is a popular one, as is MAPC-+ (MAPC-UNION, MAPC-AVERAGE, etc).
There are also MAPL-xxx functions that operate on sucessive sublists.
We have plans to extend these to work on sequences and not just lists,
but haven't done it yet (:- of course, they handle circular-lists :-)
The MAP-FUN general form takes a gob of keywords
to allow just about any mapping combination to be defined, and all the
others are defined in terms of it. They are Functions, but have
Compiler transforms that convert them into very efficient DO loops.
We can probably get the code to anyone interested.
- Kelly Murray
University of Massachusetts
Sorry if this is a repeat, but I am very interested in your conjoined mapping
functions... If you can mail it, terrific, if ftp access is better, let me
know, or if you want a tape...
Thanks,
Brad Miller
------
miller@cs.rochester.edu
miller@acorn.cs.rochester.edu
∂15-May-87 1333 Mailer@XX.LCS.MIT.EDU Re: &REST
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87 13:33:07 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 May 87 16:29-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 42955; 15 May 87 16:29:59-EDT
Received: from KITTYHAWK.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 35711; 15 May 87 13:04:19-EDT
Date: Fri, 15 May 87 13:03 EDT
From: K. Shane Hartman <SHANE@JASPER.PALLADIAN.COM>
Subject: Re: &REST
To: Common-Lisp@sail.stanford.edu
In-Reply-To: <8705142119.AA04811@bhopal.edsel.uucp>
Message-ID: <870515130345.5.SHANE@KITTYHAWK.PALLADIAN.COM>
Reply-To: K. Shane Hartman <SHANE%JASPER@LIVE-OAK.LCS.MIT.EDU>
Date: Thu, 14 May 87 14:19:29 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
...
But the kinds of folks who have tolerated the bug which Dan Wienreb so
gloriously announced are not entirely stupid. There is a market, at
least amongst some systems programmers who use lisp, to get the kind of
"last-bit tweaking" performance that a stack-allocated &rest list would
afford. Lucid's product will shortly be giving the user access to some
of the underlying primitives which permit dynamic-extent consing (the
3600's "stack list" consing is one such example).
...
In fact, we use stack allocated &REST lists exclusively. We tried using heap
allocated &REST lists and found that it significantly impaired the performance of at
least one large system. I think lisp vendors should be encouraged to provide this
sort of feature.
-[Shane]->
∂15-May-87 1403 ACUFF@SUMEX-AIM.STANFORD.EDU Re: &REST
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87 14:03:13 PDT
Date: Fri, 15 May 87 14:01:46 PDT
From: Richard Acuff <Acuff@SUMEX-AIM.STANFORD.EDU>
Subject: Re: &REST
To: berman@VAXA.ISI.EDU, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8705132124.AA02845@vaxa.isi.edu>
Message-ID: <12302647619.45.ACUFF@SUMEX-AIM.STANFORD.EDU>
For the record, in Release 3, TI has attempted, with apparent
success, to remove the restrictions on using &REST lists outside of
the dynamic scope of the parameter. (While increasing the performance
of the system, to boot.)
-- Rich
-------
∂15-May-87 1747 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU Last message to list.
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87 17:47:40 PDT
Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 12746; 15 May 87 20:48:15 EDT
Date: Fri, 15 May 87 08:45 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Last message to list.
To: common-lisp@sail.stanford.edu
cc: miller@ACORN.CS.ROCHESTER.EDU
Message-ID: <870515084522.9.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Sorry, that wasn't meant for the entire list. Apologies, etc.
Brad Miller
------
miller@cs.rochester.edu
miller@acorn.cs.rochester.edu
∂17-May-87 1532 dg%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: &REST
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87 15:32:23 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 May 87 18:30-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43116; 17 May 87 18:29:57-EDT
Received: from RAVEL.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 69423; Sun 17-May-87 17:58:22-EDT
Date: Sun, 17 May 87 17:56 est
From: dg%acorn@oak.lcs.mit.edu
To: Acuff@SUMEX-AIM.STANFORD.EDU
Subject: Re: &REST
Cc: common-lisp@SAIL.STANFORD.EDU
Date: Fri, 15 May 87 14:01:46 PDT
From: Richard Acuff <Acuff@SUMEX-AIM.STANFORD.EDU>
For the record, in Release 3, TI has attempted, with apparent
success, to remove the restrictions on using &REST lists outside of
the dynamic scope of the parameter. (While increasing the performance
of the system, to boot.)
-- Rich
-------
Are there exactly 0 restrictions now?
Does this mean that removing the restrictions actually improved the
performance of the system, or was that just coincidental?
-dg
∂18-May-87 0603 dml@nadc Addition to mailing list.
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87 06:03:07 PDT
Date: 18 May 1987 08:58:24-EDT
From: dml@NADC
To: common-lisp@sail.stanford.edu
Subject: Addition to mailing list.
I am involved in design of both expert system shells and expert systems
on PC/AT and Symbolics-3600 series. Please add me to your mailing list.
Please send any recent info you have r about: Gold Hiλill LISP, Symbolics Common Lisp
, or Kyoto Common LISP.
David Loewenstern
Naval Air Development Center
code 7013
Warminster, PA 18974-5000
<dml@nadc.arpa>
∂18-May-87 0811 FAHLMAN@C.CS.CMU.EDU Mailing List for Lucid Users
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 May 87 08:10:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 18 May 87 11:10:08-EDT
Date: Mon, 18 May 1987 11:10 EDT
Message-ID: <FAHLMAN.12303370022.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SAIL.STANFORD.EDU, AIList@STRIPE.SRI.COM
Subject: Mailing List for Lucid Users
We have set up an ARPAnet mailing list, "lucites@c.cs.cmu.edu", for the
exchange of information related to Lucid Common Lisp. This mailing list
is meant to function as a sort of informal users' group; it is not under
the control of Lucid, though some Lucid people will receive it.
"Lucites" is an appropriate channel for queries, programming hints, and
the sharing of software (large programs can be announced but should not
be distributed over this mailing list). "Lucites" is not an appropriate
channel for bug reports, commercial announcements, or sales pitches.
Because our machine's capacity to forward mail is limited, we must
reserve the right to refuse any request to add more than two recipients
to the list from any given site; if you have three or more people who
want to receive this mail, you are expected to set up you own local
redistribution list or to direct the mail to a bulletin board that your
people can access. (If anyone wants to set up a version of this list
without such restrictions, please contact us and we will gladly turn the
task over to you.)
To get your name on the list, send mail to
"lucites-request@c.cs.cmu.edu". Requests sent to us personally will be
ignored. Requests sent to the mailing list as a whole will result in
scorn and abuse being heaped upon you. If any address on the list
starts bouncing mail sent to it, it will be excised from the list at
once.
Scott E. Fahlman
David B. McDonald
Computer Science Department
Carnegie-Mellon University
∂18-May-87 1151 @RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET Introduction to a multi-byte character extension
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 May 87 11:50:56 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac05113; 18 May 87 14:19 EDT
Received: from utokyo-relay by RELAY.CS.NET id ek09318; 18 May 87 14:03 EDT
Received: by u-tokyo.junet (5.51/4.9J-1[JUNET-CSNET])
id AA19456; Mon, 18 May 87 14:09:05 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA06680; Mon, 18 May 87 14:05:32+0900
Date: Mon, 18 May 87 14:05:32+0900
From: Masayuki Ida <a37078%tansei.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8705180505.AA06680@tansei.cc.u-tokyo.junet>
To: common-lisp@SAIL.STANFORD.EDU, ida%tansei.u-tokyo.junet@RELAY.CS.NET
Subject: Introduction to a multi-byte character extension
In the separate mail, I posted a mail titled
"A multi-byte character extension proposal",
which has 740 lines.
Since I posted mails on kanji manipulation in May 1986,
I have been thinking of this problem.
I organized the kanji WG under Jeida Common Lisp committee,
and I welcomed Dr. Motoyoshi from Electro-technical Laboratory
as the chair of the WG.
I asked him and his group to make a proposal.
Their porposal was first appeared on the academic meeting
(IPSJ SIGSYM Jan. 1987) and then reported in the annual report
of Jeida, then was refined into the english version I posted
as a mail.
I believe the contents are worth to distribute in USA and
to have criticism and suggestions
as a base for multi-byte character manipulation extension
of Common Lisp.
It is a report of our kanji WG
to make a guide line for multi-byte character manipulation
in Common Lisp, not by myself only, but by the contributions of
all the members of kanji WG.
kanji WG members:
IKEO, J. (Fuji Xerox Co., Ltd.)
KIMURA, K. (Toshiba Corp.)
MURAYAMA, K. (Nippon Univac Kaisha, Ltd.)
NAKAMURA, S. (Fujitsu, Ltd.)
OKA, M. (Japan Radio Co., Ltd.)
SAKAIBARA, K. (Hitachi Co., Ltd.)
SHIOTA, E. (Nihon Symbolics Corp.)
SUGIMURA, T. (Nippon Telegraph and Telephone Corp.)
Especially, thanks to Mr. Shiota of Nippon Symbolics,
who made a first english version.
It has a digest, 4 chapters and one appendix;
Digest
1. A proposal for embedding multi-byte characters
2. Additional features for embedding multi-byte characters
3. Common parts which we implement
4. Proposed changes to CLtL to support multiple character sets
Appendix Proposed Japanese character processing facilities for Common Lisp
We tried to split the general issues on multi-byte character extension
and the japanese character manipulation.
We hope this specification will fit to any other character set handling.
Our proposal is based on the clear specification of CLtL
for character data type.
Roughly speaking,
First, we give a value larger than 256, may be 65536 or larger,
to *char-code-limit* constant.
Second, for the implementation which do not need to have
a multi-byte character feature, we propose internal-thin-things.
Third, to handle multi-byte character properly, we propose
write-width function.
We did not make a conclusion on font- style- issue.
And our proposal does not have a direct concern to the issue.
We will welcome any comments on it.
But we can not make a rapid answer to arpa.
So, please dont haste. excuse me.
We will make answers to the important questions
considering our limited budget for communication.
Masayuki Ida
∂18-May-87 1158 @RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET A multi-byte character extension proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 May 87 11:58:10 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae05113; 18 May 87 14:19 EDT
Received: from utokyo-relay by RELAY.CS.NET id el09318; 18 May 87 14:04 EDT
Received: by u-tokyo.junet (5.51/4.9J-1[JUNET-CSNET])
id AA19470; Mon, 18 May 87 14:10:20 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA06726; Mon, 18 May 87 14:06:46+0900
Date: Mon, 18 May 87 14:06:46+0900
From: Masayuki Ida <a37078%tansei.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8705180506.AA06726@tansei.cc.u-tokyo.junet>
To: common-lisp@SAIL.STANFORD.EDU, ida%tansei.u-tokyo.junet@RELAY.CS.NET
Subject: A multi-byte character extension proposal
Date: Mon, 18 May 87 09:44:19 JST
From: moto@XXX.XXX.junet (MOTOYOSHI)
To: ida@tansei.cc.u-tokyo.junet
Subject: Kanji Proposal
-------------------- Beginning of text --------------------
@Comment[-*- Mode: Text -*-]
@heading[Digest]
@heading[1. Hierarcy of characters and strings]
Let the value of char-code-limit be large enough to include all
characters.
char > string-char >= internal-string-char > standard-char
string >= internal-thin-string > simple-internal-thin-string
simple-string >= simple-internal-thin-string
string = (or internal-thin-string (vector string-char))
Type internal-thin-string and (vector string-char) are
disjoint or identical.
simple-string = (or simple-internal-thin-string
(simple-array string-char (*)))
Type simple-internal-thin-string and (simple-array
string-char (*)) are disjoint or identical.
notes: A > B means B is a subtype of A,
A >= B means B is a subtype of A or B is equal to A.
@Heading[2. Print width]
Only standard characters are required to have fix-pitched
print width. Use the newly introdued function 'write-width'
to know the print width of an expression.
@Heading[3. Functions]
Functions dealing with strings should work as before,
expect ones which change the contents of internal-thin-string
to non internal-thin-char's.
Functions producing strings should create (vector
string-char), not internal-thin-string, unless they were
explicitly specified.
Funtions comaring strings should copare them elementwise.
Therefore it is possible that a (vector string-char) is equal
to an internal-thin-string.
@newpage
@Heading[1. A proposal for embedding multi-byte characters]
The Kanji Working Group (KWG) examined implementation of facilities for
multi-byte character to Common Lisp. This report is the result of many
discussions of many proposals. Of course, this report doesn't satisfy
all proposals, but it is very close.
In order to decide on a final proposal, we chose essential and
desirable characteristics of a working multi-byte character system.
Chapter 2 describes these characteristics in some detail.
Chapter 3 describes additional features to Common Lisp which will be useful
not just for multi-byte character, but also for many other kinds of character sets.
This chapter describes internal data structures. If this proposal is
accepted in Common Lisp, it will be easy for countries to add original mechanisms.
Chapters 4 describes proposed changes to @I[Common Lisp -- The Language]
(CLtL).
@Heading[2. Additional features for embedding multi-byte characters.]
This chapter describes design principles which can be used to design
multi-byte character language extensions to Common Lisp.
There are many programming languages which can multi-byte characters.
Most of them can use multi-byte character as string character data
but not as variables or function names.
It is necessary for programming languages like Lisp that use symbolic data
to be able to process not only single-byte characters but also multi-byte characters.
That is, it should be possible to use multi-byte characters in character string and
symbols, and it must be possible to store both kinds of characters in them.
Treating multi-byte characters just like other alpha-numeric characters
means that multi-byte character must be treated as a single character object.
Many of the present implementations of Lisp treat multi-byte character as
pairs of bytes. Alternatively, they use a different data type which
doesn't permit multi-byte character to be mixed with standard characters.
Such systems are not useful for user.
Thus, the basic design principles for embedding multi-byte character to Common Lisp are:
@Begin[Itemize]
Multi-byte character should be treated like single-byte character, that is,
a multi-byte character is one character object.
@End[Itemize]
@Begin[Itemize]
A program which was coded without explicit attention for multi-byte character should
handle multi-byte character data as is.
@End[Itemize]
These principles provide sufficient functionality, but we can't ignore
efficiency. So we considered the next principle:
@Begin[Itemize]
The performance of the system in terms of CPU and memory
utilization should not be consideraly affected in programs which do not use multi-byte
characters.
@End[Itemize]
This principle is contradictory to other principles, but this can't be
ignored when we consider the users of actual systems, so we have to
compromise. We think that following methods will satisfy both of these
requirements.
@Heading[3. Common parts which we implement.]
This chapter describes the implementation of multiple character sets in Common Lisp.
To treat multi-byte characters like single-byte characters, the multi-byte character must be
included in the set of possible character codes.
We consider the following implementation methods.
@Begin[Itemize]
Add multi-byte characters by setting the variable char-code-limit to a large number.
@End[Itemize]
In this case, the single-byte character set and the multi-byte character
set must be ordered into a single sequence of character codes. This means multi-byte
character set must not overlap with the single-byte character set. This method could
be satisfied within most implementations with ease.
If we use this method, it is possible to use multi-byte characters with
fonts in Common Lisp, and operations that work for single-byte
character will also work for multi-byte character without any change.
This implementation method has problems with efficiency.
In the case that the value of character code is greater than size of 1 byte
(multi-byte characters are in this category), memory utilization is
affected. A string containing only one single-byte character is 2 bytes long.
The same problem would also occur with symbol p-names. If we can solve the problem
for strings, we can solve other problems, so we will start by considering only strings.
To avoid this memory utilization problem, it is possible to optimize and
make single-byte character strings by packing internally. In other words,
to have two kinds of data types and not show it to user. There is only one type of
data from the viewpoint of users, which means that every function which uses strings
will continue to work as defined.
This can be implemented in almost everywhere without so many costs. The only
problem occurs when a function attempts to put a multi-byte character into an optimized
and packed sigle-byte-only string. To work according to the definition, the implementation
must unpack the original packed string. This presents an implementation inefficiency which
the user may find undesirable.
One solution would be to
@Begin[Itemize]
Generate errors for operations that try to use multi-byte characters into
single-byte string and presenting two string datatypes to users.
@End[Itemize]
We propose this latter implementation. Common lisp should have 2 string
types to treat multi-byte characters efficiently. The first of these is
@b[ε1stringε0], which stores any character of type @B[ε1string-charε0], i.e.,
whose @I[ε2bitsε0] and @I[ε2fontε0] are both zero. The type of string is
@B[ε1internal-thin-stringε0] which is the optimized character string.
@B[ε1internal-thin-charε0] is a subtype of @B[ε1characterε0] and can be inserted into string
@B[ε1internal-thin-stringε0]. The predicate which tests for this type of character is
@B[ε1internal-thin-char-pε0].
The type @B[ε1internal-thin-charε0] is a subtype of @B[ε1string-charε0], and is a
supertype of @B[ε1standard-charε0].
The data type hierarchy for @B[ε1characterε0] and @B[ε1stringε0] is shown in figure 1.
@b[ε1Internal-thin-charε0] and @b[ε1string-charε0] may be equal as it is possible that situations
may arise where both sets describe the same character-set.
This is equivalent to the type of system that has only one type of character from the
viewpoint of the user as discussed in the previous chapter. This proposal permits both
kinds of implementations.
@newpage
@Begin[Verbatim]
character
|
string-char
|
internal-thin-char
|
standard-char
@Center[Fig-1.a Structure of character type]
string
|
-----------------------------------
| | |
| simple-string |
| | |
internal-thin-string | (vector string-char)
| | |
-----------------------------------
| |
| |
simple-internal-thin-string (simple-array string-char (*))
@Center[Fig-1.b Structure of string type]
@End[Verbatim]
To compare @B[ε1stringε0] characters with @B[ε1internal-thin-stringε0] characters, it is
necessary to convert both to the @B[ε1string-charε0] format. This means that
the same character is the same object regardless of whether it is found
in an @B[ε1internal-thin-stringε0] or a normal @B[ε1stringε0].
Next we must discuss character input. The proposal does not discuss what is stored
in files, nor what happens between the Lispimplementation and a terminal.
Each system will implement this in itsown way. Instead, let us discuss the data
as passed to lisp programs. We think that treating all input data as @B[ε1stringε0]
is the safest possible course. Since a symbol's p-name string should not be modified,
it can be optimized.
This may cause performance problems for programs which use only
single-byte characters. The variable @B[ε1*read-default-string-type*ε0] is
provided for these programs. When its value is @B[ε1internal-thin-stringε0], the system
expects single-byte characters only. so the system will return input data
in the form of @B[ε1internal-thin-stringε0]. Though it is possible that the system may
choose to ignore this variable.
@newpage
@Heading[4 Proposed changes to CLtL to support multiple character sets.]
In this section, we list proposed modifications to CLtL. Chapters 13,
14 and 18 of CLtL are concerned very greatly with multi-byte character, so we specify
modifications to these chapters by making a list of all constants,
functions and variables. For other chapters we specify only additional
and modifying parts. Those portions which are not mentioned are
unchanged.
@b(2 Data Types)
@b(2.5.2 Strings)
@begin(equation)
"a string is a specialized vector .... type string-char"
↓
"a string is a specialized vector .... type string-char or @B[internal-thin-char]"
@end(equation)
@b(2.15 Overlap,Inclusion and Disjointness of Types)
a description of type string-char is changed to :
Type standard-char is a subtype of @B[internal-thin-char].
@B[internal-thin-char] is a subtype of string-char. string-char is a
subtype of character.
and add the following :
Type @B[internal-thin-string] is a subtype of vector because @B[internal-thin-string] means
(vector internal-thin-char).
a description of type string is changed to :
Type string is a subtype of vector because string means (or
(vector string-char) internal-thin-string). Type (vector
string-char) and @B[internal-thin-string] are disjoint or equality.
a description of type simple-vector,simple-string ... is changed to :
Type simple-vector,simple-string and simple-bit-vector are disjoint subtype of
simple-array because each one means (simple-array t (*)),
(or (simple-array string-char (*)),(or (simple-array internal-thin-char (*)) and
(simple-array bit (*)).
and add following :
Type simple-internal-thin-string means (simple-array
internal-thin-char (*)) and is a subtype of @B[internal-thin-string].
Type (simple-array string-char (*)) and simple-internal-thin-string are disjoint or
equality.
@b(4 Type Specifiers)
@b(4.1 Type Specifier Symbols)
add followings to system defined type specifiers :
simple-internal-thin-string
internal-thin-string
internal-thin-char
@b(4.5 Type Specifiers That Specialize)
"The specialized types (vector string-char) ... data types."
↓
"The specialized types (vector internal-thin-char), (vector
string-char) and (vector bit) are so useful that they have the
special names string and bit-vector. Every implementation of Common
Lisp must provide distinct representation for string and bit-vector
as distinct specialized data types."
@begin(equation)
@b(13 Characters)
@b(13.1 Character Attributes)
char-code-limit@>[constant]
char-font-limit@>[constant]
char-bits-limit@>[constant]
@b(13.2 Predicates on Characters)
standard-char-p char@>[constant]
graphic-char-p char@>[constant]
@begin(quotation)
a description "graphic characters of font 0 are all of the same width when printed" in
the CLtL changed to "standard-char without #\Newline of font 0 are all of the same
width when printed".
@end(quotation)
string-char-p char @>[function]
internal-thin-char-p char@>[function]
@begin(quotation)
this function must be added.
the argument char must be a character object. internal-thin-char-p
is true if char can be stored into a internal-thin-string, and
otherwise is false.
@end(quotation)
alpha-char-p char@>[function]
upper-case-p char@>[function]
lower-case-p char@>[function]
both-case-p char@>[function]
"If a character is either ... alphabetic."
↓
"If a character is either uppercase or lowercase, it is necessarily character
that alpha-char-p returns true."
digit-char-p char &optional (radix 10)@>[function]
alphanumericp char@>[function]
char= character &rest more-characters@>[function]
char/= character &rest more-characters@>[function]
char< character &rest more-characters@>[function]
char> character &rest more-characters@>[function]
char<= character &rest more-characters@>[function]
char>= character &rest more-characters@>[function]
char-equal character &rest more-characters@>[function]
char-not-equal character &rest more-characters@>[function]
char-lessp character &rest more-characters@>[function]
char-greaterp character &rest more-characters@>[function]
char-not-greaterp character &rest more-characters@>[function]
char-not-lessp character &rest more-characters@>[function]
@b(13.3 Character Construction and Selection)
char-code char@>[function]
char-bits char@>[function]
char-font char@>[function]
code-char char &optional (bits 0) (font 0)@>[function]
make-char char &optional (bits 0) (font 0)@>[function]
@b(13.4 Character Conversion)
character char@>[function]
char-upcase char@>[function]
char-downcase char@>[function]
digit-char weight &optional (radix 10) (font 0)@>[function]
char-int char@>[function]
int-char char@>[function]
char-name char@>[function]
name-char char@>[function]
@b(13.5 Character control-bit functions)
char-control-bit@>[constant]
char-meta-bit@>[constant]
char-super-bit@>[constant]
char-hyper-bit@>[constant]
char-bit char name@>[function]
set-char-bit char name newvalue@>[function]
@b(14 Sequence)
@b(14.1 Simple sequence functions)
elt sequence index@>[Function]
subseq sequence start &optional end@>[Function]
copy-seq sequence@>[Function]
length sequence@>[Function]
reverse sequence@>[Function]
nreverse sequence@>[Function]
make-sequence type size &key :initial-element@>[Function]
@b(14.2 Sequence connection)
concatenate result-type &rest sequences@>[Function]
map result-type function sequence &rest more-sequences@>[Function]
some predicate sequence &rest more-sequences@>[Function]
every predicate sequence &rest more-sequences@>[Function]
notany predicate sequence &rest more-sequences@>[Function]
notevery predicate sequence &rest more-sequences@>[Function]
reduce function sequence@>[Function]
&key :from-end :start :end :initial-value
@b(14.3 Sequence correction)
fill sequence item &key :start :end@>[Function]
replace sequence1 sequence2 &key :start1 :end1 :start2 :end2@>[Function]
remove item sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
remove-if test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-if-not test sequence@>[Function]
&key :from-end :start
:end :count :key
delete item sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
remove-if test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-if-not test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-duplicates sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
delete-duplicates sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
subsutitute newitem test sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
subsutitute-if newitem test sequence@>[Function]
&key :from-end :start :end :count :key
subsutitute-if-not newitem test sequence@>[Function]
&key :from-end :start :end :count :key
nsubsutitute newitem test sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
nsubsutitute-if newitem test sequence@>[Function]
&key :from-end :start :end :count :key
nsubsutitute-if-not newitem test sequence@>[Function]
&key :from-end :start :end :count :key
@b(14.4 Search)
find item sequence @>[Function]
&key :from-end :test :test-not
:start :end :key
find-if test sequence @>[Function]
&key :from-end :start :end :key
find-if-not test sequence>[Function]
&key :from-end :start :end :key
position item sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
position-if test sequence@>[Function]
&key :from-end :start :end :key
position-if-not test sequence@>[Function]
&key :from-end :start :end :key
count item sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
count-if item sequence@>[Function]
&key :from-end :start :end :key
count-if-not item sequence@>[Function]
&key :from-end :start :end :key
mismatch sequence1 sequence2@>[Function]
&key :from-end :test :test-not
:key :start1 :start2
:end1 :end2
search sequence1 sequence2@>[Function]
&key :from-end :test :test-not
:key :start1 :start2
:end1 :end2
@b(14.5 Sort,merge)
sort sequence predicate &key :key@>[Function]
stable-sort sequence predicate &key :key@>[Function]
merge result-type sequence1 sequence2 predicate &key :key@>[Function]
@b(18 Strings)
"the type string is identical ... (array string-char (*))."
↓
"the type string is identical to the type
(or (vector internal-thin-char) (vector string-char)),
which in turn is the same as (or (array internal-thin-char (*))
(array string-char (*)))."
@b(18.3 String Construction and Manipulation)
make-string size &key :initial-element@>[function]
@begin(quotation)
add following :
To make an internal-thin-string, you should use make-array or make-sequence.
@end(quotation)
@b(22 Input/Output)
@b(22.2 Input Functions)
@b(22.2.1 Output to Character Stream)
add following :
*read-default-string-type*@>[variables]
@begin(quotation)
The value is string or internal-thin-string. This determines string that the function
read takes whether type string or internal-thin-string.
@end(quotation)
@b(22.3 Output Functions)
@b(22.3.1 Output from Character Stream)
@begin(quotation)
add following :
@end(quotation)
write-width object@>[function]
&key :unit-type :stream :escape :radix :base
:circle :pretty :label :length :case :gensym :array
@begin(quotation)
This function returns the printed width as the value of the unit
specified by :unit-type when then printed representation of
object is written to the output stream specified by :stream. It
returns nil when object includes control characters
(#\Newline,#\Tab etc). The default of :unit-type is byte. The
value which we can specify :unit-type depends on implementation.
@end(quotation)
@end(equation)
@newpage
@Heading[Appendix Proposed Japanese character processing facilities for Common Lisp.]
In addition to the modification of CLtL, here are some suggestions for systems
including Japanese characters.
1). How should system behave for Japanese characters both
under unmodified part of CLtL and the part changed for multi-byte
processing.
2). About function that are specific to Japanese and no at all related
to multi-byte processing.
Notes: All Japanese characters are constituent. JIS is a abreviation of Japanese Industry
Standard.
@begin(equation)
@b(13. Characters)
@b(13.1. Character Attributes)
char-code-limit char @>[Function]
@begin(quotation)
The value of char-code-limit should be large enough to include Japanese characters,
e.g. 65536.
@end(quotation)
@b(13.2. Predicates on Characters)
standard-char-p char @>[Function]
@begin(quotation)
Return nil for all Japanese characters.
@end(quotation)
graphic-char-p char @>[Function]
@begin(quotation)
Return t for Japanese characters.
@end(quotation)
internal-thin-char-p char @>[Function]
@begin(quotation)
The result depends on each implementation that whether the Japanese character is in
internal-thin-string or not.
@end(quotation)
alpha-char-p char @>[Function]
@begin(quotation)
Return nil for all character except alphabets in Japanese character. It depends on
each implementation whether to return t or nil for alphabets in Japanese characters.
@end(quotation)
@newpage
jis-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object. jis-char-p is true if the
argument is included in JIS C-6226, and otherwise false.
@end(quotation)
japanese-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object. japanese-char-p is true if the
argument is a Japanese character and is otherwise false. All characters that satisfy
jis-char-p must satisfy japanese-char-p; other characters might.
@end(quotation)
kanji-char-p char@>[Function]
@begin(quotation)
The argument char has to be character type object. kanji-char-p is true if the
argument is one of the 6353 Kanji characters in JIS C6226(3.1.8), the repeat symbol,
the kanji numeric zero or the same as above symbol for a total of 6356 characters
that also satisfy jis-char-p.
@end(quotation)
hiragana-char-p char@>[Function]
@begin(quotation)
The argument char has to be character type object.
hiragana-char-p is true if the argument is one of the 83
hiragana characters in JIS C6226(3.1.4), the hiragana repeat
symbol, or dakuten for a total of 85 characters that also
satisfy jis-char-p.
@end(quotation)
katakana-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object.
katakana-char-p is true if the argument is one of the 86
hiragana characters in JIS C6226(3.1.5), long-sound-symbol,
katakana-repeat symbol, or katakana-dakuten for a total of 89
characters that also satisfy jis-char-p.
@end(quotation)
kana-char-p char@>[Function]
@begin(quotation)
equivalence (or (hiragana-char-p char) (katakana-char-p char))
@end(quotation)
upper-case-p char@>[Function]
lower-case-p char@>[Function]
both-case-p char@>[Function]
@begin(quotation)
These are nil if the argument does not satisfy alpha-char-p.
Japanese characters which satisfy alpha-char-p should be treated
as normal alphabetic characters.
@end(quotation)
@newpage
digit-char-p char &optional (radix 10)@>[Function]
@begin(quotation)
digit-char-p is nil if the argument is a Japanese character.
@end(quotation)
alphanumericp char@>[Function]
@begin(quotation)
equivalence (or (alpha-char-p char) (not (null (digit-char-p char))))
@end(quotation)
char= character &rest more-characters@>[Function]
char/= character &rest more-characters@>[Function]
char< character &rest more-characters@>[Function]
char> character &rest more-characters@>[Function]
char<= character &rest more-characters@>[Function]
char>= character &rest more-characters@>[Function]
@begin(quotation)
The ordering of hiragana, katakana, kanji follows the JIS ordering.
@end(quotation)
@b(13.4 character Conversions)
char-upcase char@>[Function]
char-downcast char@>[Function]
@begin(quotation)
These return the argument if the argument does not satisfy
alpha-char-p. It depends on the implementation whether these
work on the alphabets included in JIS or not. But it should be
consistent with upper-case-p, lower-case-p, both-case-p.
@end(quotation)
@end(equation)
∂18-May-87 1547 berman@vaxa.isi.edu Format
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 May 87 15:46:52 PDT
Posted-Date: Mon, 18 May 87 15:46:42 PDT
Message-Id: <8705182246.AA12230@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA12230; Mon, 18 May 87 15:46:45 PDT
To: common-lisp@sail.stanford.edu
Subject: Format
Date: Mon, 18 May 87 15:46:42 PDT
From: Richard Berman <berman@vaxa.isi.edu>
What should this do:
(FORMAT () "~E" 3/4)
I have one implementation that produces "0.75" and another that produces
"7.5E-1". As far as I can detect, the latter MAY be correct. CLtL says, on
page 393 about the ~E directive, "If all of [the parameters] are omitted, then
the effect is to print the value using ordinary free-format
exponential-notation output; prin1 uses this format for any non-zero number
whose magnitude is less than 10↑-3 or greater than or equal to 10↑7.
"If arg is a rational number, then it is coerced to be a single-float and
then printed."
It is unclear whether: (a) the same format used by prin1 for numbers
in the given range should be used regardless of the range of the arg, or (b)
if it should print like prin1.
It seems the former interpretation may be correct, as it clearly
states that the format used is used by prin1 "for any non-zero number whose
magnitude...", and it is the *format* we are talking about, not "what prin1"
does. I would like clarification of this point.
Thanks in advance.
RB
∂18-May-87 1719 barmar@Think.COM Format
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 18 May 87 17:19:32 PDT
Received: from xavier by Think.COM via CHAOS; Mon, 18 May 87 20:21:49 EDT
Date: Mon, 18 May 87 20:18 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Format
To: Richard Berman <berman@vaxa.isi.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705182246.AA12230@vaxa.isi.edu>
Message-Id: <870518201858.7.BARMAR@XAVIER.THINK.COM>
Date: Mon, 18 May 87 15:46:42 PDT
From: Richard Berman <berman@vaxa.isi.edu>
What should this do:
(FORMAT () "~E" 3/4)
I have one implementation that produces "0.75" and another that produces
"7.5E-1". As far as I can detect, the latter MAY be correct. CLtL says, on
page 393 about the ~E directive, "If all of [the parameters] are omitted, then
the effect is to print the value using ordinary free-format
exponential-notation output; prin1 uses this format for any non-zero number
whose magnitude is less than 10↑-3 or greater than or equal to 10↑7.
"If arg is a rational number, then it is coerced to be a single-float and
then printed."
It is unclear whether: (a) the same format used by prin1 for numbers
in the given range should be used regardless of the range of the arg, or (b)
if it should print like prin1.
To me, that sentence strictly says that PRIN1 may contain code like the
following:
(when (and (not (= number 0.0))
(or (< number 1.0e-3)
(>= number 1.0e7)))
(format stream "~E" number))
which I guess corresponds to your (a).
Whether that is what was intended is a different story....
barmar
∂18-May-87 1736 Olasov.StudentNS@MIT-Multics.ARPA Communications packages in Common LISP
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87 17:36:13 PDT
Acknowledge-To: Olasov@MIT-Multics.ARPA
Date: Mon, 18 May 87 20:22 EDT
From: Olasov@MIT-Multics.ARPA
Subject: Communications packages in Common LISP
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <870519002252.487741@MIT-Multics.ARPA>
Hello,
Does anyone know of communications programs written in Common LISP for IBM
80286 type machines that can perform not only the usual modem software
functions, i.e. dialing, receiving files, sending files, answering, etc. but
which also allow the user to develop routines for processing character streams
from the foreign host, and responding to them according to user specified
directives? Alternatively, is anyone developing such applications? In either
case, I'd be very interested to hear about these applications.
Thanks,
Ben Olasov
<Olasov@MIT-MULTICS.ARPA>
∂18-May-87 2222 @RELAY.CS.NET:MURRAY@cs.umass.edu User-Visible Declarations and Proclamations
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 May 87 22:22:45 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae11645; 19 May 87 1:17 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ao13616; 19 May 87 1:11 EDT
Date: Mon, 18 May 87 12:04 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
Subject: User-Visible Declarations and Proclamations
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: CLMAIL
Because of all the interest in the Maps, I've rewritten Dan Corkill's
original code to handle sequences as well as lists (as well as other changes).
The code is now available (I'm sending it out via Netmail), and Dan
should have a paper on the Maps finished up real soon now.
Since the code now works on both sequences and lists, it must test
at run-time what kind of argument it has (similiar to the MAP-INTO code).
This could be avoided if the type was declared to be a list or vector.
I would like to solicit discussion on the possibility of providing one
or more functions or variables in Common Lisp to provide information
about any declarations or proclaimations that are in effect.
Previous mail by a number of people has indicated a desire to be able to
determine whether a variable has been proclaimed special (e.g. DEFVAR).
This is another example of the general problem.
For type declarations, something like (DECLARED-RESULT-TYPE Form) --> Type
would allow macro-expanders to possibly generate much more efficient code.
I imagine all systems with a compiler have this kind of a function in one
form or another. A system could always just return T.
What about defining the global variables *speed*, *safety*, and
*compiler-speed* to be bound to their proclaimed values?
Another possibility is to have one general function that takes as arguments
what kind of information is requested.
- Kelly Murray
University of Massachusetts
∂19-May-87 1136 Moon@STONY-BROOK.SCRC.Symbolics.COM User-Visible Declarations and Proclamations
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 11:36:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 143821; Tue 19-May-87 14:34:22 EDT
Date: Tue, 19 May 87 14:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: User-Visible Declarations and Proclamations
To: MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 18 May 87 12:04 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET
Message-ID: <870519143423.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 18 May 87 12:04 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
....
Since the code now works on both sequences and lists, it must test
at run-time what kind of argument it has (similiar to the MAP-INTO code).
This could be avoided if the type was declared to be a list or vector.
I would like to solicit discussion on the possibility of providing one
or more functions or variables in Common Lisp to provide information
about any declarations or proclaimations that are in effect.
Previous mail by a number of people has indicated a desire to be able to
determine whether a variable has been proclaimed special (e.g. DEFVAR).
This is another example of the general problem.
For type declarations, something like (DECLARED-RESULT-TYPE Form) --> Type
would allow macro-expanders to possibly generate much more efficient code.
I imagine all systems with a compiler have this kind of a function in one
form or another. A system could always just return T.
What about defining the global variables *speed*, *safety*, and
*compiler-speed* to be bound to their proclaimed values?
Another possibility is to have one general function that takes as arguments
what kind of information is requested.
This sort of thing would probably be useful, although I think it's clear that
it needs to be thought out a lot more carefully before standardizing on anything.
However, I don't think you need it for your particular application. Just expand
into a TYPECASE and rely on the compiler to constant-fold it if the type tests
have known results due to declarations. Perhaps not all compilers do this
optimization, but it's a reasonable optimization to expect.
∂19-May-87 1139 berman@vaxa.isi.edu ~% Directive
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 11:39:16 PDT
Posted-Date: Tue, 19 May 87 11:38:22 PDT
Message-Id: <8705191838.AA02897@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA02897; Tue, 19 May 87 11:38:54 PDT
To: common-lisp@sail.stanford.edu
Subject: ~% Directive
Date: Tue, 19 May 87 11:38:22 PDT
From: Richard Berman <berman@vaxa.isi.edu>
Hi again.
do you know what this should do?
(FORMAT NIL "~-1%")
CLtL pg 397 says
"This outputs a #\Newline character, thereby terminating the current output
line and beginning a new one (see TERPRI). ~n% outputs n newlines. No arg is
used..."
No mention of <1 values being ignored, errors, etc. Which is it? Eh?
RB
∂19-May-87 1220 FAHLMAN@C.CS.CMU.EDU ~% Directive
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 12:20:33 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 19 May 87 15:19:54-EDT
Date: Tue, 19 May 1987 15:19 EDT
Message-ID: <FAHLMAN.12303677629.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Richard Berman <berman@VAXA.ISI.EDU>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: ~% Directive
In-reply-to: Msg of 19 May 1987 14:38-EDT from Richard Berman <berman at vaxa.isi.edu>
do you know what this should do?
(FORMAT NIL "~-1%")
Two choices:
1. "It is an error."
2. "Crank up the monitor's voltage and send a lethal blast of X-rays
into the face of the person issuing such a silly command."
Since not all machines can support solution 2, we should probably go
with 1, even though 2 is the more elegant and long-lasting solution.
But seriously, there seem to be a number of places in the format
directives where negative numbers would make no sense. I don't think
that all of these are explicitly flagged. This should probably be fixed
up in the standard, but until then it seems reasonable to assume
non-negative integers unless there's some obvious meaning for the
negative case.
-- Scott
∂19-May-87 1347 berman@vaxa.isi.edu More FORMAT
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 13:47:40 PDT
Posted-Date: Tue, 19 May 87 13:47:25 PDT
Message-Id: <8705192047.AA04062@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA04062; Tue, 19 May 87 13:47:27 PDT
To: common-lisp@sail.stanford.edu
Subject: More FORMAT
Date: Tue, 19 May 87 13:47:25 PDT
From: Richard Berman <berman@vaxa.isi.edu>
Oh yeah, and what about using non-defined flags, like so:
(FORMAT NIL "~:%")
Ignore?
Error?
I am testing a couple implementations which handle such things differently
(one implementation generaly ignores things which were not defined
specifically in CLtL, the other always signals an error for such things.)
MORE HAIR SPLITTING:
Page 389, CLtL:
as regards ~:@R, what if the arg is zero? There is no old roman for this.
One implementation just prints 0, the other signals an error!
Another case: ~:@R again.
Given an argument above 3999, the "forgiving" implementation just prints it as
a decimal integer. The "unforgiving" implimentation causes an error.
Is this 'cuz the old romans didn't count pas 3999 or somethin'?
The above is also true for ~@R.
Now, for ~:R...
Is there an authoritative source on how one spells the zero ordinance? Is it
"ZEROTH" or "ZEROETH". These implementation give different results.
-----------------------------
A related subject.
Both these implementations accept the following:
(setq x (make-array 10 :element-type 'string-char :fill-pointer 0))
(format x "test")
X => "test"
I can not find any reference that indicates a string may be used as a stream.
The nearest thing is on page 331, WITH-OUTPUT-TO-STRING. This appears to
exactly describe the behavior described above (as if the following
transformation had occured)
(with-output-to-string (foo x) (format foo "test"))
However, I don't find anything in FORMAT which says this is expected or
allowed. Of course, (STREAMP X) => NIL.
One of these implementations even violates this further, by extending X if it
goes beyond 10 characters. I can find absolutely nothing to allow this, as it
is not :adjustable. In fact, every possible justifying reference to allowing
the above FORMAT would still cause an error (or would just ignore) in the case
of over extension.
HELP!
RB
∂19-May-87 1511 Moon@STONY-BROOK.SCRC.Symbolics.COM More FORMAT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 15:11:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144146; Tue 19-May-87 17:46:18 EDT
Date: Tue, 19 May 87 17:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: More FORMAT
To: Richard Berman <berman@vaxa.isi.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705192047.AA04062@vaxa.isi.edu>
Message-ID: <870519174622.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 19 May 87 13:47:25 PDT
From: Richard Berman <berman@vaxa.isi.edu>
....
(setq x (make-array 10 :element-type 'string-char :fill-pointer 0))
(format x "test")
X => "test"
I can not find any reference that indicates a string may be used as a stream.
Look harder, it's right at the top of page 386. It's not being used as a stream,
it's being used as a format destination.
One of these implementations even violates this further, by extending X if it
goes beyond 10 characters. I can find absolutely nothing to allow this, as it
is not :adjustable.
In some implementations all arrays are adjustable even if you didn't explicitly
ask for an adjustable array in make-array.
∂19-May-87 1524 berman@vaxa.isi.edu Re: More FORMAT
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 15:23:59 PDT
Posted-Date: Tue, 19 May 87 15:22:17 PDT
Message-Id: <8705192222.AA05902@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA05902; Tue, 19 May 87 15:22:29 PDT
To: "David A. Moon" <Moon@stony-brook.scrc.symbolics.com>
Cc: Richard Berman <berman@vaxa.isi.edu>, common-lisp@sail.stanford.edu
Subject: Re: More FORMAT
In-Reply-To: Your message of Tue, 19 May 87 17:46:00 -0400.
<870519174622.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 19 May 87 15:22:17 PDT
From: Richard Berman <berman@vaxa.isi.edu>
Thanks for the ref: on page 386. As for some implementations defaulting to
adjustable arrays, page 288 says, of the :adjustable keyword in make-array,
"...if specified and not nil, indicates that it must be possible to alter the
array's size dynamically after it is created. This argument defaults to nil."
Granted, this does not say that a value of nil prohibits adjustability, but
only that it must be adjustable if given non-nil. Do you interpret this as
meaning "nil value *may* indicate it is possible to alter ...."?
I hope there is a way to have guaranteed non-adjustable arrays!
RB
∂19-May-87 1608 barmar@Think.COM Re: More FORMAT
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 19 May 87 16:08:01 PDT
Received: from ueberweg by Think.COM via CHAOS; Tue, 19 May 87 19:09:55 EDT
Date: Tue, 19 May 87 19:07 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: More FORMAT
To: Richard Berman <berman@vaxa.isi.edu>
Cc: David A. Moon <Moon@stony-brook.scrc.symbolics.com>,
common-lisp@sail.stanford.edu
In-Reply-To: <8705192222.AA05902@vaxa.isi.edu>
Message-Id: <870519190744.8.BARMAR@UEBERWEG.THINK.COM>
Date: Tue, 19 May 87 15:22:17 PDT
From: Richard Berman <berman@vaxa.isi.edu>
Thanks for the ref: on page 386. As for some implementations defaulting to
adjustable arrays, page 288 says, of the :adjustable keyword in make-array,
"...if specified and not nil, indicates that it must be possible to alter the
array's size dynamically after it is created. This argument defaults to nil."
Granted, this does not say that a value of nil prohibits adjustability, but
only that it must be adjustable if given non-nil. Do you interpret this as
meaning "nil value *may* indicate it is possible to alter ...."?
:adjustable T means "I plan on adjusting this array, so make sure it is
adjustable." :adjustable NIL means "I don't plan on adjusting this
array, so don't go out of your way to make it adjustable." The response
to the latter on some systems is, "oh, it's no trouble."
I hope there is a way to have guaranteed non-adjustable arrays!
Some systems (Maclisp, for example!) don't have non-adjustable arrays.
This is no different from the element type. If you specify
:element-type 'integer you are requiring Lisp to create an array that
can at least hold integers. It doesn't prohibit it from creating an
array that can hold other things, too.
The way to think of these things is as hints or declarations. Telling
the system that you only plan on storing integers or that you don't plan
on adjusting the array allows it to choose an optimal array format. If
a particular implementation chooses not to perform a particular
optimization it doesn't affect the semantics.
barmar
∂19-May-87 1618 Daniels.pa@Xerox.COM Re: More FORMAT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 May 87 16:18:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAY 87 16:10:39 PDT
Date: 19 May 87 16:10 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: More FORMAT
In-reply-to: Richard Berman <berman@vaxa.isi.edu>'s message of Tue, 19
May 87 13:47:25 PDT
To: berman@vaxa.isi.edu
cc: common-lisp@sail.stanford.edu
Message-ID: <870519-161039-1087@Xerox>
I believe that all format directives not covered by the standard should
be "is an error." This includes providing incorrect arguments to the
format directives as well as using undefined format directives.
Implementations are then free to ignore the colon in "~:%", signal an
error, or even provide an extension that gives this a meaning. In the
latter case, it would be nice if there were a mode that does flag
nonstandard usages.
~@R and ~:@R are abominations, but if we have to have them, I agree that
the standard should specify what ranges of numbers are covered by these
directives. Cleanup committe: has anyone looked into this?
I can not find any reference that indicates a string may be
used as a stream. The nearest thing is on page 331,
WITH-OUTPUT-TO-STRING. This appears to exactly describe the
behavior described above (as if the following transformation had
occured) (with-output-to-string (foo x) (format foo "test"))
However, I don't find anything in FORMAT which says this is
expected or allowed. Of course, (STREAMP X) => NIL.
CLtL p. 386: "If destination is a string with a fill pointer, then in
effect the output characters are added to the end of the string (as if
by use of VECTOR-PUSH-EXTEND)." So the implementation in question was
correct in appending the formatted output to the string.
One of these implementations even violates this further, by
extending X if it goes beyond 10 characters. I can find absolutely
nothing to allow this, as it is not :adjustable. In fact, every
possible justifying reference to allowing the above FORMAT would
still cause an error (or would just ignore) in the case of over
extension.
Indeed, CLtL p. 296 explicitly states that if the fill pointer gets too
large and the vector is not adjustable, an error should be signalled.
∂19-May-87 1802 sandra%orion@cs.utah.edu All arrays can be adjustable?
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 18:02:29 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA12308; Tue, 19 May 87 19:03:37 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA04735; Tue, 19 May 87 19:03:33 MDT
Date: Tue, 19 May 87 19:03:33 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8705200103.AA04735@orion.utah.edu>
Subject: All arrays can be adjustable?
To: common-lisp@sail.stanford.edu
From: barmar@Think.COM (Barry Margolin)
Date: 19 May 87 23:07:00 GMT
Date: Tue, 19 May 87 15:22:17 PDT
From: Richard Berman <berman@vaxa.isi.edu>
I hope there is a way to have guaranteed non-adjustable arrays!
Some systems (Maclisp, for example!) don't have non-adjustable arrays.
The way to think of these things is as hints or declarations. Telling
the system that you only plan on storing integers or that you don't plan
on adjusting the array allows it to choose an optimal array format. If
a particular implementation chooses not to perform a particular
optimization it doesn't affect the semantics.
barmar
It's definitely wrong for make-array to randomly return adjustable arrays
when the user doesn't specifically ask for them. From page 289: "If
make-array is called with the :adjustable, :fill-pointer, and :displaced-to
arguments all either unspecified or nil, then the resulting array is
guaranteed to be a simple array."
This actually sounds like a good problem for the cleanup committee to
address. As I see it, a correct implementation needs to do two things:
(1) Ensure that things like svref work correctly on things that
are supposed to be simple arrays:
(svref (make-array 3 :initial-element 'foo) 0)
(2) Ensure that user programs can distinguish arrays that are supposed to
be simple arrays from those that are not, regardless of whether or not
simple arrays use the same internal representation as non-simple arrays.
(simple-vector-p (make-array 3 :initial-element 'foo)) => true
(simple-vector-p (make-array 3 :adjustable t)) => false
I do agree that this problem is similar to whether or not the implementation
has specialized representations for arrays that can only contain a specified
element type. However, this issue has the same semantic problems as above.
Would you like to get a general vector back when you're expecting a simple
string? Especially if it doesn't even print like a string?
-Sandra
-------
∂19-May-87 1835 Moon@STONY-BROOK.SCRC.Symbolics.COM All arrays can be adjustable?
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 18:35:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144366; Tue 19-May-87 21:34:22 EDT
Date: Tue, 19 May 87 21:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705200103.AA04735@orion.utah.edu>
Message-ID: <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 19 May 87 19:03:33 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
It's definitely wrong for make-array to randomly return adjustable arrays
when the user doesn't specifically ask for them.
I disagree. See below.
From page 289: "If
make-array is called with the :adjustable, :fill-pointer, and :displaced-to
arguments all either unspecified or nil, then the resulting array is
guaranteed to be a simple array."
This actually sounds like a good problem for the cleanup committee to
address. As I see it, a correct implementation needs to do two things:
(1) Ensure that things like svref work correctly on things that
are supposed to be simple arrays:
(svref (make-array 3 :initial-element 'foo) 0)
Of course.
(2) Ensure that user programs can distinguish arrays that are supposed to
be simple arrays from those that are not, regardless of whether or not
simple arrays use the same internal representation as non-simple arrays.
I don't see anything in CLtL that requires this. It seems like a bad
idea, because it would require all implementations to be more complex
without giving any benefit to the user. The concept of simple arrays
exists because in some implementations they can be more efficient than
full arrays, not because people have a need to write application programs
that use simple arrays. Simple arrays don't give any extra expressive
power.
I do agree that this problem is similar to whether or not the implementation
has specialized representations for arrays that can only contain a specified
element type. However, this issue has the same semantic problems as above.
Would you like to get a general vector back when you're expecting a simple
string? Especially if it doesn't even print like a string?
If you think about it for a moment I think you'll realize how false this
analogy is. No one is proposing to change how anything prints, or indeed to
do anything other than not enforce a restriction. The distinction between
strings and general vectors is quite different from the distinction between
simple arrays and full arrays. I believe Margolin's original analogy was
a different one, referring to the lack of semantic problems when you ask
for an array that can only hold integers and get an array that can hold
anything.
∂19-May-87 2000 DLA@DIAMOND.S4CC.Symbolics.COM All arrays can be adjustable?
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 19 May 87 19:59:51 PDT
Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88321; Tue 19-May-87 22:21:35 EDT
Date: Tue, 19 May 87 22:21 EDT
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: sandra%orion@cs.utah.edu
cc: common-lisp@sail.stanford.edu, DLA@DIAMOND.S4CC.Symbolics.COM
In-Reply-To: <8705200103.AA04735@orion.utah.edu>
Message-ID: <870519222134.7.DLA@LIMPKIN.S4CC.Symbolics.COM>
Date: Tue, 19 May 87 19:03:33 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
It's definitely wrong for make-array to randomly return adjustable arrays
when the user doesn't specifically ask for them.
I don't think the issue is whether or not users can tell whether arrays
are simple or adjustable. The issue is what action CL primitives should
take with respect to extending arrays, if that would be a plausible
option of their contract.
∂19-May-87 2000 @DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM All arrays can be adjustable?
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 19 May 87 19:59:54 PDT
Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88320; Tue 19-May-87 22:18:43 EDT
Date: Tue, 19 May 87 22:18 EDT
From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%orion@cs.utah.edu
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870519221837.3.CYPHERS@RAVEN.S4CC.Symbolics.COM>
Date: Tue, 19 May 87 21:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 19 May 87 19:03:33 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
It's definitely wrong for make-array to randomly return adjustable arrays
when the user doesn't specifically ask for them.
I disagree. See below.
I mopstly agree with you, but the bottom of page 28 seems to imply that
you can make arrays which are not to be adjusted, and this is one of the
properties of simple arrays.
One use of a non-adjustable array might be when you know that the array
is big enough for your program, and if something which automatically
adjusts adjustable arrays tries to adjust your array to make it bigger,
that means your program is broken somehow. Rather than letting the
array get grown until you run out of address space to discover this
error, it would be desirable to get an error when the array tried to get
bigger than the size you originally limited it to. Why something like
this is tied up in the concept of "simple" arrays I don't know; it seems
that an array which is able to provide this service may be less simple
to implement in some implementations. Maybe the concept of "simple" is
what is bogus?
∂19-May-87 2342 KMP@STONY-BROOK.SCRC.Symbolics.COM adjustable arrays
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 23:42:25 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144502; Wed 20-May-87 02:41:11 EDT
Date: Wed, 20 May 87 02:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: adjustable arrays
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%orion@cs.utah.edu
cc: common-lisp@sail.stanford.edu, kmp@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870520024109.4.KMP@TSUKUBA.SCRC.Symbolics.COM>
I think you are both expressing reasonable and relatively coherent
views of the world.
The real problem is that CLtL is not explicit enough to distinguish between
the two cases. It has insufficient concept exposition about adjustable
arrays to clearly indicate the intent of the authors about what properties
were intentional and which were accidental. Consequently, people made up
their own concepts.
The problem with incomplete specs like this is that there are multiple
extrapolations which are compatible with the base spec, and those
extrapolations are not necessarily compatible with each other. This result
acts as a real barrier to portability at times.
I can relate to Moon's claims because I use the lispm a lot and believe it to
be an internally consistent correct reading of CLtL in this area. On the
other hand, it's not what I had expected from reading the CL manual. As such,
I know first hand that other people can have internally consistent but
differing readings. I also know first hand that it's a pain to port code
between dialects with conflicting views because it's hard to test the code
in one implementation and have any confidence that it will run in the other.
Whether we decide on the conservative reading that Sandra and others have
pushed or the less conservative reading that Moon asserts was intended, the
important thing is that the manual say clearly what will happen so that users
can simply read the book and know what to expect with no need to do lengthy
deductions about the consequences of what they have or have not read.
I think the issues are clearly understood and little more is to be gained by
prolonged debate at this time. A process (X3J13) exists for introducing
changes/corrections to CLtL and I think that process should now be asked to
do its job by addressing that issue.
∂20-May-87 0248 Mailer@XX.LCS.MIT.EDU Re: More FORMAT
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 02:48:00 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 20 May 87 05:46-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43464; 20 May 87 05:42:35-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 1; 20 May 87 01:29:56-EDT
Date: Wed, 20 May 87 01:01 EDT
From: Don Morrison <dfm@JASPER.PALLADIAN.COM>
Subject: Re: More FORMAT
To: berman@vaxa.isi.edu
cc: Moon@stony-brook.scrc.symbolics.com, common-lisp@sail.stanford.edu
In-Reply-To: <8705192222.AA05902@vaxa.isi.edu>
Message-ID: <870520010156.3.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>
Date: Tue, 19 May 87 15:22:17 PDT
From: Richard Berman <berman@vaxa.isi.edu>
I hope there is a way to have guaranteed non-adjustable arrays!
Why? Is there any thing that non-adjustable arrays are good for the adjustable
arrays are not? I thought it was just that you paid a performance hit for
adjustability in some (typically non-special-microcode) implementations.
∂20-May-87 0635 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM All arrays can be adjustable?
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 20 May 87 06:35:41 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88382; Wed 20-May-87 09:33:14 EDT
Date: Wed, 20 May 87 09:37 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>, David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>, Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>,
Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, common-lisp@sail.stanford.edu
In-Reply-To: <8705200103.AA04735@orion.utah.edu>,
<870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<870519222134.7.DLA@LIMPKIN.S4CC.Symbolics.COM>,
<870519221837.3.CYPHERS@RAVEN.S4CC.Symbolics.COM>,
<870520024109.4.KMP@TSUKUBA.SCRC.Symbolics.COM>
Message-ID: <870520093735.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Maybe if we could figure out how to express the various types of arrays
using set language we wouldn't accidentally invert phrases. For
example, I think everybody agrees that simple is a subset of
(intersect not-adjustable not-fill-pointer not-displaced)
That's the >only< thing that phrase says. It can't be inverted,
conversed, contra-positived, or anything to say that simple arrays are
not adjustable. The contra-positive (the only thing provably true) is
that the UNION of adjustable, fill-pointered or displaced arrays is a
subset of non-simple arrays.
∂20-May-87 0836 DLW@ALDERAAN.SCRC.Symbolics.COM Re: More FORMAT
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 20 May 87 08:36:23 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83485; Wed 20-May-87 11:35:51 EDT
Date: Wed, 20 May 87 11:35 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: More FORMAT
To: Daniels.pa@Xerox.COM, berman@vaxa.isi.edu
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870519-161039-1087@Xerox>
Message-ID: <870520113503.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No
Date: 19 May 87 16:10 PDT
From: Daniels.pa@Xerox.COM
Indeed, CLtL p. 296 explicitly states that if the fill pointer gets too
large and the vector is not adjustable, an error should be signalled.
However, it does not state that (make-array 5) produces an array that it
not adjustable. No implementation is required to support explicitly
non-adjustable arrays. It's too bad that CLtL is so unclear about this.
But, for example, if you look at the documentation of :adjustable on p.
288, note the use of the word "must": this is trying to say that
:adjustable t means that it "must" be adjustable, whereas :adjustable
nil means that it need not be adjustable, although it can be.
∂20-May-87 0841 DLW@ALDERAAN.SCRC.Symbolics.COM All arrays can be adjustable?
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 20 May 87 08:41:23 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83482; Wed 20-May-87 11:31:34 EDT
Date: Wed, 20 May 87 11:31 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: Cyphers@YUKON.SCRC.Symbolics.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870519221837.3.CYPHERS@RAVEN.S4CC.Symbolics.COM>
Message-ID: <870520113117.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Tue, 19 May 87 22:18 EDT
From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>
Date: Tue, 19 May 87 21:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 19 May 87 19:03:33 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
It's definitely wrong for make-array to randomly return adjustable arrays
when the user doesn't specifically ask for them.
I disagree. See below.
I mopstly agree with you, but the bottom of page 28 seems to imply that
you can make arrays which are not to be adjusted, and this is one of the
properties of simple arrays.
"and is not to have its size adjusted" is just another ambiguous phrase.
I read this to mean "and its caller is not allowed to assume that it
would work to adjust its size"; that is, it makes no promises that
adjusting the size would work.
There is no question what the intention of the writers of CLtL was. The
idea of "simple" arrays was to provide a way for stock hardware
implementations to implement simpler arrays more cheaply, without making
any impositions on architectures in which there's no extra cost for more
complex arrays. The wording in CLtL was intended to convey this idea,
but apparently it falls short.
Yes, it might be useful to have a feature that provides for an array
that is guaranteed to signal an error if there is an attempt to adjust
it. However, CL has no such feature, and I think it's only slightly
useful. Arrays have enough features as it is; you have to draw the line
somewhere.
∂20-May-87 0851 franz!ficl!jkf@ucbarpa.Berkeley.EDU adjustable arrays
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 08:51:39 PDT
Received: by ucbarpa.Berkeley.EDU (5.57/1.25)
id AA29057; Wed, 20 May 87 08:51:38 PDT
Received: from ficl by franz (5.5/3.14)
id AA20347; Wed, 20 May 87 08:20:10 PDT
Received: by ficl (5.5/3.14)
id AA16895; Wed, 20 May 87 08:20:04 PDT
From: franz!ficl!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <ficl!jkf>
Message-Id: <8705201520.AA16895@ficl>
To: common-lisp@sail.stanford.edu
Subject: adjustable arrays
Date: Wed, 20 May 87 08:20:02 PDT
To give another data point to the discussion: in our lisp (Extended
Common Lisp) we have a variety of internal array implementations to
satisify the various combinations of array features the user might
select. I expect most other implemenations do likewise. Many of
these internal implementations are adjustable however our lisp will
refuse to adjust any array not explictly specified as adjustable by
the user. Since we're going to extra work to refuse to do something
that we could easily do, there should be a good reason for it, and
in our case that reason is portabilty. If a user wants needs an adjustable
array and doesn't specify it, then he'll find out right away instead
of when he ports his code to another lisp.
I don't feel that returning a adjustable array when the user
doesn't ask for one 'is an error'. When you call 'make-array' you ask
for the minimum set of features you need and the system returns
the best thing it can. Implementations should be encouraged to return
the best match to the user's request, thus if the user doesn't ask for
an adjustable array, then returning an non-adjustable array is better
than returning an adjustable one, but both are valid.
- John Foderaro
Franz Inc.
∂20-May-87 0859 FAHLMAN@C.CS.CMU.EDU All arrays can be adjustable?
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 08:59:32 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 May 87 11:51:45-EDT
Date: Wed, 20 May 1987 11:51 EDT
Message-ID: <FAHLMAN.12303901889.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: All arrays can be adjustable?
In-reply-to: Msg of 20 May 1987 09:37-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
Maybe if we could figure out how to express the various types of arrays
using set language we wouldn't accidentally invert phrases. For
example, I think everybody agrees that simple is a subset of
(intersect not-adjustable not-fill-pointer not-displaced)
That's the >only< thing that phrase says. It can't be inverted,
conversed, contra-positived, or anything to say that simple arrays are
not adjustable. The contra-positive (the only thing provably true) is
that the UNION of adjustable, fill-pointered or displaced arrays is a
subset of non-simple arrays.
Gee, it's been a while since I hacked formal logic in any serious way,
but it seems to be true that if X is a subset of the intersection of A,
B, C, and D, then X is (provably) a subset of A. I cheated and used
little pictures instead of contrapositives (my religion forbids the use
of contrapositives, even among consenting adults), but I think it's
still true. Maybe I should go audit a logic course and see what I'm
doing wrong.
-- Scott
∂20-May-87 0955 @RELAY.CS.NET:DUSSUD%Jenner@TI-CSL.CSNET [dg%acorn@oak.lcs.mit.edu: Re: &REST]
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 May 87 09:55:48 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ad00189; 20 May 87 12:25 EDT
Received: from ti-csl by RELAY.CS.NET id ad24696; 20 May 87 12:01 EDT
Received: by tilde id AA16282; Wed, 20 May 87 08:54:45 CDT
Message-Id: <2757506096-3811281@Jenner>
Date: Wed, 20 May 87 08:54:56 CDT
From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
To: dg%acorn@LIVE-OAK.LCS.MIT.EDU, "Daniel L. Cerys" <Cerys@xx.arpa>
Cc: common-lisp@SAIL.STANFORD.EDU, Acuff@SUMEX-AIM.STANFORD.EDU
Subject: [dg%acorn@oak.lcs.mit.edu: Re: &REST]
In-Reply-To: Msg of Tue, 19 May 87 09:58:50 EDT from "Daniel L. Cerys" <Cerys@xx.ARPA>
Date: Sun, 17 May 87 17:56 est
From: dg%acorn@oak.lcs.mit.edu
Subject: Re: &REST
To: Acuff@SUMEX-AIM.STANFORD.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
Date: Fri, 15 May 87 14:01:46 PDT
From: Richard Acuff <Acuff@SUMEX-AIM.STANFORD.EDU>
For the record, in Release 3, TI has attempted, with apparent
success, to remove the restrictions on using &REST lists outside of
the dynamic scope of the parameter. (While increasing the performance
of the system, to boot.)
-- Rich
-------
Are there exactly 0 restrictions now?
Does this mean that removing the restrictions actually improved the
performance of the system, or was that just coincidental?
-dg
There are 0 restrictions on using &REST lists outside of the dynamic
scope of the parameter. The way we do it is the following:
We have a new datatype for &rest args (A list on the stack). When
somebody tries to store a pointer of type stack-list, the microcode
triggers a copy. The copy process is recursive if the &rest args are
nested. The copy is done is such a way that it preserves EQness. Since
the data type check is hardware assisted, it is done without performance
penalty.
The performance improvement is coincidental.
Patrick.
∂20-May-87 1013 johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK
Received: from [14.0.0.9] by SAIL.STANFORD.EDU with TCP; 20 May 87 10:13:14 PDT
Received: from cvaxa.sussex.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09225; 20 May 87 18:07 BST
From: John Williams <johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK>
Date: Wed, 20 May 87 17:35:43 gmt
Message-Id: <5464.8705201735@cvaxa.sussex.ac.uk>
To: common-lisp@sail.stanford.edu
Am I right in thinking that Cltl does not specify the result(s)
returned by the following functions:
DISASSEMBLE
DRIBBLE
ED
INSPECT
PROCLAIM
ROOM
∂20-May-87 1039 las@bfly-vax.bbn.com
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 20 May 87 10:39:36 PDT
To: common-lisp@sail.stanford.edu
Date: 20 May 87 13:41:08 EDT (Wed)
From: las@bfly-vax.bbn.com
Regarding Roman numerals:
Having recently visited Roman-numeral land, I too was curious about implementations that
did not print Romam numerals above 3999 (new) or 4999 (old). Not recalling the entirety
of my elementary school education, I consulted the Table of Numbers in
Webster's Ninth New Collegiate Dictionary (page 812).
Roman numerals above 1000 are written with "bars" above them. These have no ascii
equivalent. Use of lower case is equivalent to the upper case use. Below, a hyphen
following a letter is to be interpreted as a bar above it.
The numerals above 1000 are:
5,000 V-
10,000 X-
100,000 C-
1,000,000 M-
The question is: after the year 4999, how will Common Lisp print film copyright
dates?
- Larry Stabile
∂20-May-87 1123 barmar@Think.COM DISASSEMBLE, et all return values
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 20 May 87 11:23:06 PDT
Received: from xavier by Think.COM via CHAOS; Wed, 20 May 87 14:24:21 EDT
Date: Wed, 20 May 87 14:21 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: DISASSEMBLE, et all return values
To: John Williams <johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <5464.8705201735@cvaxa.sussex.ac.uk>
Message-Id: <870520142124.6.BARMAR@XAVIER.THINK.COM>
Date: Wed, 20 May 87 17:35:43 gmt
From: John Williams <johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK>
Am I right in thinking that Cltl does not specify the result(s)
returned by the following functions:
DISASSEMBLE
DRIBBLE
ED
INSPECT
PROCLAIM
ROOM
It doesn't specify return values in my copy of the book. That means
that a portable program should not do anything with the values of these
functions. As far as CLtL is concerned, they are only useful for their
side-effects.
barmar
∂20-May-87 1158 berman@vaxa.isi.edu Re: More FORMAT
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 11:56:57 PDT
Posted-Date: Wed, 20 May 87 11:55:34 PDT
Message-Id: <8705201855.AA02717@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA02717; Wed, 20 May 87 11:55:56 PDT
To: Don Morrison <DFM%JASPER@live-oak.lcs.mit.edu>
Cc: common-lisp@sail.stanford.edu
Subject: Re: More FORMAT
In-Reply-To: Your message of Wed, 20 May 87 01:01:00 -0400.
<870520010156.3.DFM@WHITBY.PALLADIAN.COM>
Date: Wed, 20 May 87 11:55:34 PDT
From: Richard Berman <berman@vaxa.isi.edu>
As someone else mentioned, it can be more than useful to know that something
is causing an array to grow. It seems reduntant to me to have an :adjustable
keyword if there are no clear semantics to :adjustable nil, only to
:adjustable T. Especially when :adjustable (non-nil) == :adjustable nil.
Or perhaps we need a :non-adjustable keyword, just to keep our semantics
consistent, where :non-adjustable T means "definitely" non-adjustable, and
:non-adjustable nil means "maybe non-adjustable"?
RB
∂20-May-87 1210 berman@vaxa.isi.edu
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 12:10:14 PDT
Posted-Date: Wed, 20 May 87 12:05:53 PDT
Message-Id: <8705201905.AA02808@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA02808; Wed, 20 May 87 12:05:56 PDT
To: las@bfly-vax.bbn.com
Cc: common-lisp@sail.stanford.edu, berman@vaxa.isi.edu
In-Reply-To: Your message of Wed, 20 May 87 13:41:08 -0400.
<8705201807.AA02149@vaxa.isi.edu>
Date: Wed, 20 May 87 12:05:53 PDT
From: Richard Berman <berman@vaxa.isi.edu>
My only question re: roman numerals is: what does *common lisp* do for values
above the specified range (or unspecified, so far as the spec is concerned).
Do we just not print romans above certain values? What is printed instead?
Etc.?
RB
∂20-May-87 1239 berman@vaxa.isi.edu las@bfly-vax.bbn.com
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 12:38:50 PDT
Posted-Date: Wed, 20 May 87 12:38:44 PDT
Message-Id: <8705201938.AA03160@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA03160; Wed, 20 May 87 12:38:46 PDT
To: common-lisp@sail.stanford.edu
Subject: las@bfly-vax.bbn.com
Date: Wed, 20 May 87 12:38:44 PDT
From: Richard Berman <berman@vaxa.isi.edu>
To everyone else: sorry.
I can't send you mail. You will have to call me. 213-822-1511
RB
∂20-May-87 1247 las@bfly-vax.bbn.com
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 20 May 87 12:47:39 PDT
To: berman@vaxa.isi.edu
CC: common-lisp@sail.stanford.edu
Date: 20 May 87 15:44:22 EDT (Wed)
From: las@bfly-vax.bbn.com
More on Roman numerals:
I haven't given the question a large amount of thought, but it seems to me that the
printed representation of a number is as much tied to the font characteristics of a given
output device as it is to the "style" or "language" of the number.
This problem seems to apply to other areas as well, such as non-English printing.
Rumbling about Roman numerals only scratches the surface.
I see the following solutions to the Roman problem:
1. Print in decimal, when Roman won't work.
2. Extend the Roman system, e.g., V-CCIV = 5204.
3. Deem it an error.
4. Extend the character set and sense properties of the output
device when printing. This, of course, does not solve
the problem in general.
I think I like (1) best, since it guarantees a number recognizable by
English-speaking humans (which the rest of Common Lisp seems geared to),
and does not lead us into the quagmire of querying devices, extending
character sets, etc. The need to address those problems, however,
is not far off.
-Larry Stabile
∂20-May-87 1251 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM All arrays can be adjustable?
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 20 May 87 12:50:54 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88582; Wed 20-May-87 15:48:49 EDT
Date: Wed, 20 May 87 15:53 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: All arrays can be adjustable?
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12303901889.BABYL@C.CS.CMU.EDU>
Message-ID: <870520155306.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Well, I guess I blew it. (I had it right when I first wrote it and then
made the mistake of thinking too much and conversed everything.) The
idea still stands: figure out formal relationships and draw conclusions
from them. What I meant, in IF-THEN language, was
Statement:
IF not adjustable, and
no fill-pointer, and
not displaced
THEN
simple
Contrapositive (for those that believe in it):
IF not simple
THEN
adjustable, or
fill-pointer, or
displaced
I agree with whoever (Moon?) said that simple is largely a semantic
concept that allows implementations to get leverage if they can.
∂20-May-87 1359 peck@Sun.COM Order of evaluation in PUSH (& PUSHNEW)
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 20 May 87 13:59:28 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
id AA03347; Wed, 20 May 87 13:55:56 PDT
Received: from denali.sun.com by snail.sun.com (3.2/SMI-3.2)
id AA05880; Wed, 20 May 87 13:55:28 PDT
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA29640; Wed, 20 May 87 13:58:00 PDT
Message-Id: <8705202058.AA29640@denali.sun.com>
To: common-lisp@sail.stanford.edu
Subject: Order of evaluation in PUSH (& PUSHNEW)
Date: Wed, 20 May 87 13:57:56 -0700
From: peck@Sun.COM
In the form: (push (ref1) (car (ref2)))
It is unclear whether (ref1) should be evaluated before (ref2).
CLtL, page 270 states:
" The *effect* of (PUSH Item Place) is *roughly* equivalent to
(SETF Place (CONS Item Place))
except that the latter would evaluate any subforms of Place twice
while PUSH takes care to evaluate them only once."
CLtL, in discussion of generalized variable accessors/modifiers,
page 99 states:
"Macros that manipulate generalized variables must guarentee the "obvious"
semantics: subforms of generalized-variable references are evaluated ...
in exactly the same order as they appear in the *source* program."
[Is this the *definition* of "obvious" semantics...?]
PUSH is in the class of "Macros that manipulate generalized variables".
However, even though the *generalized-variable references*
are evaluated with the "obvious" semantics, should standard macros
necessarily evaluate *all* their arguments in the "obvious" order?
The problem is that PUSH is [almost] specified as a macro which expands
to something in which its args are not in the "obvious" source order.
Shall we just agree that PUSH does not follow the "obvious" semantics?
Lucic and Franz evaluate (ref2) then (ref1)
Symbolics evaluate (ref1) then (ref2)
Lucid:
> (macroexpand '(push (ref1) (car (ref2))))
((LAMBDA (#:G2)
((LAMBDA (#:G1) (SET-CAR #:G2 #:G1))
(CONS (REF1) (CAR #:G2))))
(REF2))
T
ExCL:
<cl> (macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G8 (REF2))
(#:G7 (CONS (REF1) (CAR #:G8))))
(EXCL::.INV-CAR #:G8 #:G7))
T
Symbolics:
Command: (macroexpand '(push (ref1) (car (ref2))))
(LET* ((#:G5 (REF1))
(#:G4 (REF2)))
NIL
(SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))
T
Definitely one for the CL comittee.
∂20-May-87 1551 berman@vaxa.isi.edu :fill-pointer maybe
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 15:51:51 PDT
Posted-Date: Wed, 20 May 87 15:51:43 PDT
Message-Id: <8705202251.AA05057@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA05057; Wed, 20 May 87 15:51:46 PDT
To: common-lisp@sail.stanford.edu
Subject: :fill-pointer maybe
Date: Wed, 20 May 87 15:51:43 PDT
From: Richard Berman <berman@vaxa.isi.edu>
Another maybe!
On pg 288, about the :fill-pointer keyword to MAKE-ARRAY:
"This argument specifies that the array should have a fill pointer. If this
option is specified and not NIL, the array must be one-dimensional. The value
is used to initialize the fill pointer for the array. If the value T is
specified, the length of the array is used...etc."
It doesn't say that an array with :fill-pointer nil *doesn't* have a fill
pointer, although it implies that multi-dimensional arrays can't or don't have
one. I have one implmentation where all vectors have fill pointers, and
another that strictly reports an error when vector-push-extend is called on an
array with no fill pointer.
Any idea if this is intentional relaxation, or oversight?
RB
∂20-May-87 1623 berman@vaxa.isi.edu arrays
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 16:22:57 PDT
Posted-Date: Wed, 20 May 87 16:22:48 PDT
Message-Id: <8705202322.AA05367@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA05367; Wed, 20 May 87 16:22:51 PDT
To: common-lisp@sail.stanford.edu
Subject: arrays
Date: Wed, 20 May 87 16:22:48 PDT
From: Richard Berman <berman@vaxa.isi.edu>
On bit vectors:
on page 12:
"One dimensional arrays of bits (that is, of integers whose values are 0 or 1)
are called bit vectors"
implies that any array of all 0 and 1 integers is a bit vector.
Page 29:
"All implementations are also required to provide specialized arrays of bits,
that is, arrays of type (array bit); the one-dimensional instances of this
specialization are called bit-vectors."
Page 286:
"Vectors whose elements are restricted to type bit are called bit-vectors"
This implies strongly that a bit vector won't let one store any other value
than 0 or 1.
So, is this a bit vector?
#(1 0 0 1) and should things like BIT-NOT which specifically want a bit vector
work on it. Does it return a general vector like this in this case rather
than something like *0110???
It is my *opinion* that #(1 0 0 1) is not a bit vector because there is a
precise input style for such (like *1001) and bit vectors are specialized.
What do you think? Is this a real maybe?
RB
∂20-May-87 1647 FAHLMAN@C.CS.CMU.EDU :fill-pointer maybe
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 16:47:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 May 87 19:47:14-EDT
Date: Wed, 20 May 1987 19:47 EDT
Message-ID: <FAHLMAN.12303988451.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Richard Berman <berman@VAXA.ISI.EDU>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: :fill-pointer maybe
In-reply-to: Msg of 20 May 1987 18:51-EDT from Richard Berman <berman at vaxa.isi.edu>
Richard,
It looks to me like you and some others are missing a key concept.
There are an awful lot of places in CLtL where it is specified that
certain things have to work, but where the manual is silent on what
happens if those conditions don't hold. A classic example is a built-in
function whose arguments "must" be of a certain type. As a rule, these
unspecified situations should be considered to "be an error".
That phrase means that a legal Common Lisp implementation is free to
extend the language to handle this situation in some allegedly useful
way; it is not required to signal an error or to self-destruct.
Portable Common Lisp code may not depend on any such extensions, but an
implementation is free to extend all it wants.
In some cases where CLtL is silent, it is an oversight and a case can be
made for changing to a "signals an error" case or for specifying exactly
what must happen in that situation. In most cases, however, the
language is left open-ended deliberately. The feeling of the designers
was that Common Lisp is a living, growing language, and we didn't want
to bind it all up too tightly by trying to specify EVERYTHING. "Signals
an error" was only specified in those cases where we felt that an error
signal was essential and where detecting the error would not impose too
great a performance penalty on some calsses of machine.
Now, if an implementation takes advantage of its freedom to extend the
language, and if it does not provide a compiler mode or some other tool
that flags the use of such non-portable extensions, then that
implementation is unsuitable for developing portable applications. (I
could name some names, but I won't.) Nevertheless, such implementations
are perfectly legal and are operating within the spirit of the Common
Lisp spec. The language was meant to be extensible; that was an
important part of the original charter that we set for ourselves.
So, for the purposes of validation, you should treat these unspecified
cases as "is an error" cases and leave them alone (unless it is unclear
whether the case is or is not specified). It couldn't hurt to make a
list of the ones you encounter for later discussion, but in almost all
cases the default answer is "this situation is an error; implementations
may do what they like". It is the job of the validation suite to make
sure that the cases that ARE specified are handled correctly.
-- Scott
∂20-May-87 1658 FAHLMAN@C.CS.CMU.EDU arrays
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 16:58:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 May 87 19:57:39-EDT
Date: Wed, 20 May 1987 19:57 EDT
Message-ID: <FAHLMAN.12303990345.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Richard Berman <berman@VAXA.ISI.EDU>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: arrays
In-reply-to: Msg of 20 May 1987 19:22-EDT from Richard Berman <berman at vaxa.isi.edu>
"Vectors whose elements are restricted to type bit are called bit-vectors"
This implies strongly that a bit vector won't let one store any other value
than 0 or 1.
This one is right in my opinion. Sloppy wording in some of the other
descriptions you quote.
So, is this a bit vector?
#(1 0 0 1)
No.
should things like BIT-NOT which specifically want a bit vector
work on it. Does it return a general vector like this in this case rather
than something like *0110???
They have to work on bit vectors. It is an error to give it anything
else. If an implementation wants to handle general vectors that happen
to be full of 1's and 0's, that's a legal extension; in such cases, it
is no business of Common Lisp what it returns.
-- Scott
∂20-May-87 1840 berman@vaxa.isi.edu arrays
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 16:22:57 PDT
Posted-Date: Wed, 20 May 87 16:22:48 PDT
Message-Id: <8705202322.AA05367@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA05367; Wed, 20 May 87 16:22:51 PDT
To: common-lisp@sail.stanford.edu
Subject: arrays
Date: Wed, 20 May 87 16:22:48 PDT
From: Richard Berman <berman@vaxa.isi.edu>
On bit vectors:
on page 12:
"One dimensional arrays of bits (that is, of integers whose values are 0 or 1)
are called bit vectors"
implies that any array of all 0 and 1 integers is a bit vector.
Page 29:
"All implementations are also required to provide specialized arrays of bits,
that is, arrays of type (array bit); the one-dimensional instances of this
specialization are called bit-vectors."
Page 286:
"Vectors whose elements are restricted to type bit are called bit-vectors"
This implies strongly that a bit vector won't let one store any other value
than 0 or 1.
So, is this a bit vector?
#(1 0 0 1) and should things like BIT-NOT which specifically want a bit vector
work on it. Does it return a general vector like this in this case rather
than something like *0110???
It is my *opinion* that #(1 0 0 1) is not a bit vector because there is a
precise input style for such (like *1001) and bit vectors are specialized.
What do you think? Is this a real maybe?
RB
∂20-May-87 1840 FAHLMAN@C.CS.CMU.EDU :fill-pointer maybe
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 16:47:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 May 87 19:47:14-EDT
Date: Wed, 20 May 1987 19:47 EDT
Message-ID: <FAHLMAN.12303988451.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Richard Berman <berman@VAXA.ISI.EDU>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: :fill-pointer maybe
In-reply-to: Msg of 20 May 1987 18:51-EDT from Richard Berman <berman at vaxa.isi.edu>
Richard,
It looks to me like you and some others are missing a key concept.
There are an awful lot of places in CLtL where it is specified that
certain things have to work, but where the manual is silent on what
happens if those conditions don't hold. A classic example is a built-in
function whose arguments "must" be of a certain type. As a rule, these
unspecified situations should be considered to "be an error".
That phrase means that a legal Common Lisp implementation is free to
extend the language to handle this situation in some allegedly useful
way; it is not required to signal an error or to self-destruct.
Portable Common Lisp code may not depend on any such extensions, but an
implementation is free to extend all it wants.
In some cases where CLtL is silent, it is an oversight and a case can be
made for changing to a "signals an error" case or for specifying exactly
what must happen in that situation. In most cases, however, the
language is left open-ended deliberately. The feeling of the designers
was that Common Lisp is a living, growing language, and we didn't want
to bind it all up too tightly by trying to specify EVERYTHING. "Signals
an error" was only specified in those cases where we felt that an error
signal was essential and where detecting the error would not impose too
great a performance penalty on some calsses of machine.
Now, if an implementation takes advantage of its freedom to extend the
language, and if it does not provide a compiler mode or some other tool
that flags the use of such non-portable extensions, then that
implementation is unsuitable for developing portable applications. (I
could name some names, but I won't.) Nevertheless, such implementations
are perfectly legal and are operating within the spirit of the Common
Lisp spec. The language was meant to be extensible; that was an
important part of the original charter that we set for ourselves.
So, for the purposes of validation, you should treat these unspecified
cases as "is an error" cases and leave them alone (unless it is unclear
whether the case is or is not specified). It couldn't hurt to make a
list of the ones you encounter for later discussion, but in almost all
cases the default answer is "this situation is an error; implementations
may do what they like". It is the job of the validation suite to make
sure that the cases that ARE specified are handled correctly.
-- Scott
∂20-May-87 1840 FAHLMAN@C.CS.CMU.EDU arrays
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 16:58:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 20 May 87 19:57:39-EDT
Date: Wed, 20 May 1987 19:57 EDT
Message-ID: <FAHLMAN.12303990345.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Richard Berman <berman@VAXA.ISI.EDU>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: arrays
In-reply-to: Msg of 20 May 1987 19:22-EDT from Richard Berman <berman at vaxa.isi.edu>
"Vectors whose elements are restricted to type bit are called bit-vectors"
This implies strongly that a bit vector won't let one store any other value
than 0 or 1.
This one is right in my opinion. Sloppy wording in some of the other
descriptions you quote.
So, is this a bit vector?
#(1 0 0 1)
No.
should things like BIT-NOT which specifically want a bit vector
work on it. Does it return a general vector like this in this case rather
than something like *0110???
They have to work on bit vectors. It is an error to give it anything
else. If an implementation wants to handle general vectors that happen
to be full of 1's and 0's, that's a legal extension; in such cases, it
is no business of Common Lisp what it returns.
-- Scott
∂20-May-87 1844 Moon@STONY-BROOK.SCRC.Symbolics.COM Order of evaluation in PUSH (& PUSHNEW)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 May 87 18:44:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 145741; Wed 20-May-87 20:56:15 EDT
Date: Wed, 20 May 87 20:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Order of evaluation in PUSH (& PUSHNEW)
To: peck@Sun.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705202058.AA29640@denali.sun.com>
Message-ID: <870520205618.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 20 May 87 13:57:56 -0700
From: peck@Sun.COM
In the form: (push (ref1) (car (ref2)))
It is unclear whether (ref1) should be evaluated before (ref2).
The intention of the two paragraphs on page 99
Other macros that manipulate generalized variables include ... push ....
Macros that manipulate generalized variables must guarantee...
subforms of generalized-variable references are evaluated ...
in exactly the same order as they appear in the *source* program.
was to require (ref1) to be evaluated before (ref2). If some
implementations fail to follow this, that's evidence that this part
of the specification is not considered universally important, but
I don't think it changes the language.
I hadn't realized until I read your message that the book is actually
ambiguous (here as in so many other places). The quoted paragraphs could
be taken to restrict order of evaluation only of the subforms of
(car (ref2)), not all of the subforms of the push form. I'm sure
this weaker interpretation was not what was intended, and the discussion
of (setf reference value) later on the same page supports that,
since value is not a subform of a generalized-variable reference.
I personally think it's pretty dangerous for order of evaluation to
be unspecified and implementation-dependent, so I would prefer to
leave the language the way I claim it was intended to be, and as part
of the standardization process write a less ambiguous specification.
∂20-May-87 1844 Moon@STONY-BROOK.SCRC.Symbolics.COM arrays
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 May 87 18:44:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 145711; Wed 20-May-87 20:20:50 EDT
Date: Wed, 20 May 87 20:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: arrays
To: Richard Berman <berman@vaxa.isi.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705202322.AA05367@vaxa.isi.edu>
Message-ID: <870520202050.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 20 May 87 16:22:48 PDT
From: Richard Berman <berman@vaxa.isi.edu>
On bit vectors:
on page 12:
"One dimensional arrays of bits (that is, of integers whose values are 0 or 1)
are called bit vectors"
implies that any array of all 0 and 1 integers is a bit vector.
Page 29:
"All implementations are also required to provide specialized arrays of bits,
that is, arrays of type (array bit); the one-dimensional instances of this
specialization are called bit-vectors."
Page 286:
"Vectors whose elements are restricted to type bit are called bit-vectors"
This implies strongly that a bit vector won't let one store any other value
than 0 or 1.
I think the imprecise language on page 12 should not be assumed to overrule
the more precise language on pages 29 and 286. So bit-vector and bit-array
refer to the specialized types. Another way of saying this is that you cannot
change whether an object is a bit-vector (or a bit-array) by using setf of aref,
or indeed by using any other Common Lisp feature (read the description of the
:element-type argument to adjust-array carefully).
It is my *opinion* that #(1 0 0 1) is not a bit vector because there is a
precise input style for such (like *1001) and bit vectors are specialized.
I'm sure you're right.
∂20-May-87 1902 rauen@CLS.LCS.MIT.EDU Roman numeral hacking.
Received: from CLS.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 19:02:33 PDT
Received: by CLS.LCS.MIT.EDU (4.12/4.7); Wed, 20 May 87 22:07:31 edt
Date: Wed, 20 May 87 22:07:31 edt
From: rauen@CLS.LCS.MIT.EDU (James R. Rauen)
Message-Id: <8705210207.AA16268@CLS.LCS.MIT.EDU>
To: common-lisp@sail.stanford.edu
Subject: Roman numeral hacking.
How about just throwing more M's in front? (6666 = MMMMMMDCLXVI).
The case I'd worry about is zero. The Romans didn't have a zero;
maybe (format nil "~@R" 0) should return "".
--Jim
∂20-May-87 1911 ibuki!weaver@labrea.stanford.edu Order of evaluation in PUSH
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 19:10:13 PDT
Received: by labrea.stanford.edu; Wed, 20 May 87 18:08:28 PDT
Received: by ibuki.UUCP (1.4/4.7)
id AA3211335; Wed, 20 May 87 17:19:21 pdt
Date: Wed, 20 May 87 17:19:21 pdt
From: ibuki!weaver@labrea.stanford.edu (Eric Weaver)
Message-Id: <8705210019.AA3211335@ibuki.UUCP>
To: labrea!common-lisp@sail.arpa
Subject: Order of evaluation in PUSH
Date: Wed, 20 May 87 13:57:56 -0700
From: labrea!peck@Sun.COM
In the form: (push (ref1) (car (ref2)))
It is unclear whether (ref1) should be evaluated before (ref2).
....
Lucid and Franz evaluate (ref2) then (ref1)
Symbolics evaluate (ref1) then (ref2)
KCL falls in the former group:
(macroexpand '(push (ref1) (car (ref2)))) =>
(LET* ((#:G7 (REF2)) (#:G8 (CONS (REF1) (CAR #:G7))))
(PROGN (RPLACA #:G7 #:G8) #:G8))
∂20-May-87 1955 edsel!bhopal!jonl@navajo.stanford.edu [adjustable arrays?] More FORMAT
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 19:55:39 PDT
Received: by navajo.stanford.edu; Wed, 20 May 87 19:53:13 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA00421; Wed, 20 May 87 19:25:54 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03071; Wed, 20 May 87 19:27:34 PDT
Date: Wed, 20 May 87 19:27:34 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705210227.AA03071@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!berman%vaxa.isi.edu@navajo.stanford.edu,
navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 19 May 87 17:46 EDT <870519174622.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [adjustable arrays?] More FORMAT
Re: In some implementations all arrays are adjustable even if you didn't
explicitly ask for an adjustable array in make-array.
Isn't this a bug? It certainly provides a loophole for non-portable code
that isn't reasonably detectable as non-portable. For CLtL says
(1) on p289 that certain arguments to make-array "guarantee" that the
result will be a simple array;
(2) and on p28 that a simple array "is not to have its size adjusted
dynamically after creation".
You can imagine how someone using a system that doesn't detect this error
will fare when trying to run on another system that really can't adjust
simple arrays.
-- JonL --
∂20-May-87 2037 quiroz@cs.rochester.edu Re: Order of evaluation in PUSH (& PUSHNEW)
Received: from CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 20:37:38 PDT
Received: by cayuga.cs.rochester.edu (5.52/b) id AA02470; Wed, 20 May 87 23:36:11 EDT
Received: from loopback by yed.cs.rochester.edu (3.2/b) id AA00246; Wed, 20 May 87 23:38:54 EDT
Message-Id: <8705210338.AA00246@yed.cs.rochester.edu>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: peck@Sun.COM, common-lisp@sail.stanford.edu
Summary: Left to right seems correct. Unspecified might be better.
Subject: Re: Order of evaluation in PUSH (& PUSHNEW)
In-Reply-To: Your message of Wed, 20 May 87 20:56:00 -0400.
<870520205618.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 20 May 87 23:38:50 -0400
From: quiroz@cs.rochester.edu
I agree that the letter and spirit of CLtL strongly suggest that
the order of evaluation should be left to right. This is so mainly
because that is the way things normally go in Common Lisp, and so
the programmer must expect that behavior unless explicitly told not
to.
However, specifying strict left to right order of evaluation kills a
substantial amount of parallelism in argument evaluation. At least,
it makes it harder to recognize when the arguments of a function
call can be parallelized.
I am almost sure this has been raised before and probably the
original committee even considered this, but as I am new to the list,
I haven't seen this discussed: Was it ever considered to leave the
order of evaluation in function calls unspecified (or less
restricted) than in the current version? I am thinking of something
along the lines of saying that, except for special forms, other
evaluable forms are evaluated by:
1- determining the function to call or macro to expand.
2- computing the arguments, if a function.
3- calling the function (or (eval (macroexpand....))).
1- and 2- could go in parallel, or 1- could be guaranteed to occur
before 2-.
It is obvious that certain forms have no meaning but for an order of
evaluation (progn,...) and others need special rules for whether an
argument even gets eval'd (and, or, ...). But that's why all of
these forms are 'special', and pure applicative thinking [:-)] makes
it unnecessary to depend on the order of evaluation for the normal
function calls. I suspect that the original committee had a really
good reason to tie up this part of the language, but I cannot think
of one...
=Cesar
(Of course, if this has been hashed time and again, please just
point me to the relevant archives.)
--------
Cesar Augusto Quiroz Gonzalez
Department of Computer Science {allegra|seismo}!rochester!quiroz
University of Rochester or
Rochester, NY 14627 quiroz@cs.rochester.edu
∂20-May-87 2134 FAHLMAN@C.CS.CMU.EDU Order of evaluation in PUSH (& PUSHNEW)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 21:34:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 21 May 87 00:34:04-EDT
Date: Thu, 21 May 1987 00:33 EDT
Message-ID: <FAHLMAN.12304040661.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: quiroz@CS.ROCHESTER.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Order of evaluation in PUSH (& PUSHNEW)
In-reply-to: Msg of Wed 20 May 87 23:38:50 -0400 from quiroz at cs.rochester.edu
In the original design discussions, we briefly considered leaving the
order of argument evaluation undefined in order to make life easier for
some future parallel version of Common Lisp. However, we felt that the
question of what should go into a parallel Lisp was an open research
issue (it still is). We decided that designing a good serial Lisp was
plenty hard enough, and that worrying about various half-baked ideas for
a parallel Lisp would be a distraction we didn't need. So the design
went forward with parallel processing explicitly excluded from the
design criteria; given that stance, tying down the order of evaluation
seemed to be a good idea for portability.
Even if we had left order of argument evaluation open, this change by
itself would only buy you a factor of two or so on the average, and
that's with no overhead for splitting and merging processes.
-- Scott
∂20-May-87 2209 Mailer@XX.LCS.MIT.EDU [dg%acorn@oak.lcs.mit.edu: Re: &REST]
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 22:09:27 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 May 87 01:07-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43633; 21 May 87 01:08:30-EDT
Received: from CHUGACH.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 110; 21 May 87 00:44:33-EDT
Date: Thu, 21 May 87 00:44 EDT
From: Jeff Gibbons <jeff@JASPER.PALLADIAN.COM>
Subject: [dg%acorn@oak.lcs.mit.edu: Re: &REST]
To: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>,
dg%acorn@LIVE-OAK.LCS.MIT.EDU, Daniel L. Cerys <Cerys@xx.arpa>
cc: common-lisp@SAIL.STANFORD.EDU, Acuff@SUMEX-AIM.STANFORD.EDU
In-Reply-To: <2757506096-3811281@Jenner>
Message-ID: <870521004419.0.JEFF@CHUGACH.PALLADIAN.COM>
Reply-To: Jeff Gibbons <JEFF%JASPER@LIVE-OAK.LCS.MIT.EDU>
Date: Wed, 20 May 87 08:54:56 CDT
From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
... in Release 3, TI ...
There are 0 restrictions on using &REST lists outside of the dynamic
scope of the parameter. ...
Patrick.
This claim may be true but don't be fooled into thinking they are fully blessed
lists. Try:
(defun trouble (&rest x) (rplacd x '(a b c)))
(trouble 1 2 3) => Hello, debugger!
Jeff Gibbons
∂20-May-87 2254 edsel!bhopal!jonl@navajo.stanford.edu All arrays can be adjustable?
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 22:54:16 PDT
Received: by navajo.stanford.edu; Wed, 20 May 87 22:51:50 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01603; Wed, 20 May 87 22:43:20 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03359; Wed, 20 May 87 22:45:04 PDT
Date: Wed, 20 May 87 22:45:04 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705210545.AA03359@bhopal.edsel.uucp>
To: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: David L. Andre's message of Tue, 19 May 87 22:21 EDT <870519222134.7.DLA@LIMPKIN.S4CC.Symbolics.COM>
Subject: All arrays can be adjustable?
Re: I don't think the issue is whether or not users can tell whether arrays
are simple or adjustable. . . .
Whether or not that is the issue with Loosemore's complaint, it is indeed a
requirement of Common Lisp -- a user need only do (typep x 'simple-array).
See CLtL page 34 where simple-array is defined as a subtype of array.
Note also that everywhere "subtype" is used, it means "proper subtype".
-- JonL --
∂21-May-87 0556 @diamond.s4cc.symbolics.com,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM [adjustable arrays?] More FORMAT
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 05:56:39 PDT
Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by navajo.stanford.edu with TCP; Thu, 21 May 87 05:52:42 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 88819; 21 May 87 08:53:17 EDT
Date: Thu, 21 May 87 08:57 EDT
From: David C. Plummer <DCP@quabbin.scrc.symbolics.com>
Subject: [adjustable arrays?] More FORMAT
To: Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>,
navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!berman%vaxa.isi.edu@navajo.stanford.edu,
navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: <8705210227.AA03071@bhopal.edsel.uucp>
Message-Id: <870521085729.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Wed, 20 May 87 19:27:34 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
...
You can imagine how someone using a system that doesn't detect this error
will fare when trying to run on another system that really can't adjust
simple arrays.
"You can imagine how someone using a system that doesn't do
number-of-argument checking will fare ..."
As I recall, the number-of-argument discussion did happen several months
ago, and by the strict reading of CLtL it "is an error" to supply the
wrong number of arguments but implementations are not required to
"signal an error." To me, this array discussion should fall in the same
class:
- What "is an error?"
- What "signals an error?"
- What implementation freedom should there be?
- How important are some of these to various parts of the language?
For example, I would rank number of argument checking considerably
more important than worrying about allowing some systems to adjust
even simple arrays.
∂21-May-87 0725 DALY@IBM.COM validation suite
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 21 May 87 07:25:38 PDT
Date: 21 May 1987, 09:45:11 EDT
From: Timothy Daly <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <052187.094511.daly@ibm.com>
Subject: validation suite
Is there a publically available validation suite of programs
for common lisp?
∂21-May-87 0938 moss!tk@harvard.harvard.edu Re: Notice on Kyoto Common Lisp distribution (query)
Received: from HARVARD.HARVARD.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 09:38:07 PDT
Received: by harvard.harvard.edu; Thu, 21 May 87 12:26:46 EDT
Received: by RUTGERS.EDU (5.54/1.14) with UUCP
id AA13987; Thu, 21 May 87 12:34:38 EDT
Received: by moss.ATT.COM (smail2.5)
id AA16386; 21 May 87 11:21:06 EDT (Thu)
To: common-lisp@sail.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Thu, 30 Apr 1987 16:56 EDT <FAHLMAN.12298714494.BABYL@C.CS.CMU.EDU>
Subject: Re: Notice on Kyoto Common Lisp distribution (query)
Date: 21 May 87 11:21:06 EDT (Thu)
From: tk@moss.att.com (Tom Kirk)
Message-Id: <8705211121.AA16386@moss.ATT.COM>
Does anyone have new information about the availability of KCL, or
what the distribution mechanism will be? I'd appreciate any current
knowledge anyone could pass along.
Thanks,
tom kirk
-------
tk@nosc, tk@moss.att.com
∂21-May-87 0945 larus%paris.Berkeley.EDU@Berkeley.EDU Re: Order of evaluation in PUSH (& PUSHNEW)
Received: from [128.32.150.46] by SAIL.STANFORD.EDU with TCP; 21 May 87 09:44:58 PDT
Received: by paris.Berkeley.EDU (5.57/1.25)
id AA24598; Thu, 21 May 87 09:43:20 PDT
From: larus%paris.Berkeley.EDU@berkeley.edu (James Larus)
Message-Id: <8705211643.AA24598@paris.Berkeley.EDU>
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Cc: quiroz@cs.rochester.edu, common-lisp@sail.stanford.edu
Subject: Re: Order of evaluation in PUSH (& PUSHNEW)
In-Reply-To: Your message of Thu, 21 May 87 00:33:00 EDT.
<FAHLMAN.12304040661.BABYL@C.CS.CMU.EDU>
Date: Thu, 21 May 87 09:43:16 PDT
Leaving the order of evaluation of actual parameters unspecified (a la
Scheme) would help some serial, as well as parallel, implementations.
Consider a machine that uses registers for passing parameters and
evaluating expressions. If a compiler is free to reorder the
evaluation of expressions, it can evaluate the more complex ones using
the (empty) registers, then evaluate the other ones directly into
their target registers. From personal experience on SPUR, this
freedom would produce noticeably better code and reduce the number of
temporaries that have to be allocated by the register allocator.
Of course, some existing programs would break. But a good argument
can be made that these programs were dependent an implementation
artifact.
/Jim
PS Did the CL committee ever decide which sentence actually *requires*
left-to-right evaluation of formals?
∂21-May-87 1019 DLW@ALDERAAN.SCRC.Symbolics.COM [adjustable arrays?] More FORMAT
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 21 May 87 10:19:46 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 84258; Thu 21-May-87 13:18:16 EDT
Date: Thu, 21 May 87 13:17 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: [adjustable arrays?] More FORMAT
To: edsel!bhopal!jonl@navajo.stanford.edu
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8705210227.AA03071@bhopal.edsel.uucp>
Message-ID: <870521131752.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 20 May 87 19:27:34 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Isn't this a bug? It certainly provides a loophole for non-portable code
that isn't reasonably detectable as non-portable.
No. As Fahlman explained clearly in an earlier message, providing
extensions that make it harder to determine portability is in no way a
"bug" or "violation of Common Lisp".
∂21-May-87 1124 @DIAMOND.S4CC.Symbolics.COM:PTW@YUKON.SCRC.Symbolics.COM Re: Order of evaluation in PUSH (& PUSHNEW)
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 21 May 87 11:24:06 PDT
Received: from TIGGER.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88979; Thu 21-May-87 14:19:26 EDT
Date: Thu, 21 May 87 14:19 EDT
From: P. T. Withington <PTW@YUKON.SCRC.Symbolics.COM>
Subject: Re: Order of evaluation in PUSH (& PUSHNEW)
To: James Larus <larus%paris.Berkeley.EDU@berkeley.edu>, Scott E. Fahlman <Fahlman@c.cs.cmu.edu>
cc: quiroz@cs.rochester.edu, common-lisp@sail.stanford.edu
In-Reply-To: <8705211643.AA24598@paris.Berkeley.EDU>
Message-ID: <870521141924.9.PTW@TIGGER.S4CC.Symbolics.COM>
I see no reason to require evaluation order of arguments when there is
already a mechanism to enforce it: use LET* where evaluation order is
important. A good compiler should be able to optimize away the implied
temporaries when the expressed evaluation order matches the
implementation evaluation order.
∂21-May-87 1148 berman@vaxa.isi.edu Re: :fill-pointer maybe
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 11:48:42 PDT
Posted-Date: Thu, 21 May 87 11:48:24 PDT
Message-Id: <8705211848.AA10759@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA10759; Thu, 21 May 87 11:48:27 PDT
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Cc: common-lisp@sail.stanford.edu
Subject: Re: :fill-pointer maybe
In-Reply-To: Your message of Wed, 20 May 87 19:47:00 -0400.
<FAHLMAN.12303988451.BABYL@C.CS.CMU.EDU>
Date: Thu, 21 May 87 11:48:24 PDT
From: Richard Berman <berman@vaxa.isi.edu>
Scott, I get the picture. What I may be able to do is still put in checks to
cause these "is an error" conditions, with messages that if anything other
than "strict" results are obtained, the report mentions that it is optional or
implementation dependent, or whatever.
Like if no error "is signalled" (which would be the strictest interpretation
of "is an error"), then I would report that, with the above modifier.
How's that sound?
RB
∂21-May-87 1156 berman@vaxa.isi.edu Re: validation suite
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 11:56:23 PDT
Posted-Date: Thu, 21 May 87 11:55:10 PDT
Message-Id: <8705211855.AA10809@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA10809; Thu, 21 May 87 11:55:28 PDT
To: Timothy Daly <DALY@ibm.com>
Cc: common-lisp@sail.stanford.edu, berman@vaxa.isi.edu
Subject: Re: validation suite
In-Reply-To: Your message of 21 May 87 00:00:00 +0000.
<052187.094511.daly@ibm.com>
Date: Thu, 21 May 87 11:55:10 PDT
From: Richard Berman <berman@vaxa.isi.edu>
Dear Tim,
Subscribe to CL-VALIDATION@sail.stanford.edu. Get its archive, which is not
too long. Look it over.
RB
∂21-May-87 1220 FAHLMAN@C.CS.CMU.EDU :fill-pointer maybe
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 12:20:30 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 21 May 87 15:20:04-EDT
Date: Thu, 21 May 1987 15:20 EDT
Message-ID: <FAHLMAN.12304201957.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Richard Berman <berman@VAXA.ISI.EDU>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: :fill-pointer maybe
In-reply-to: Msg of 21 May 1987 14:48-EDT from Richard Berman <berman at vaxa.isi.edu>
Sounds fine, though I wouldn't waste a lot of effort looking for
extensions to flag. The most important task is to flag those places
where an implementation falls short, rather than those places where it
does more than it has to.
-- Scott
∂21-May-87 1323 Mailer@xx.lcs.mit.edu All arrays can be adjustable?
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 13:23:42 PDT
Received: from XX.LCS.MIT.EDU by navajo.stanford.edu with TCP; Thu, 21 May 87 13:18:58 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 May 87 16:19-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43733; 21 May 87 16:20:33-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 149; 21 May 87 15:20:33-EDT
Date: Thu, 21 May 87 15:20 EDT
From: Don Morrison <dfm@jasper.palladian.com>
Subject: All arrays can be adjustable?
To: edsel!bhopal!jonl@navajo.stanford.edu
Cc: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu,
navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: <8705210545.AA03359@bhopal.edsel.uucp>
Message-Id: <870521152017.2.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@live-oak.lcs.mit.edu>
Date: Wed, 20 May 87 22:45:04 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
See CLtL page 34 where simple-array is defined as a subtype of array.
Note also that everywhere "subtype" is used, it means "proper subtype".
CLtL, page 33: "If x is a supertype of y, then any object of type y is also of type x,
and y is said to be a subtype of x." Doesn't sound like "proper subtype" to me.
Also, in both Symbolics and Lucid, (subtypep x x) => t for every type I tried.
∂21-May-87 1347 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Order of evaluation in PUSH (& PUSHNEW)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 May 87 13:46:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 146808; Thu 21-May-87 16:42:06 EDT
Date: Thu, 21 May 87 16:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Order of evaluation in PUSH (& PUSHNEW)
To: P. T. Withington <PTW@YUKON.SCRC.Symbolics.COM>
cc: James Larus <larus%paris.Berkeley.EDU@berkeley.edu>, Scott E. Fahlman <Fahlman@c.cs.cmu.edu>,
quiroz@cs.rochester.edu, common-lisp@sail.stanford.edu
In-Reply-To: <870521141924.9.PTW@TIGGER.S4CC.Symbolics.COM>
Message-ID: <870521164208.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 21 May 87 14:19 EDT
From: P. T. Withington <PTW@YUKON.SCRC.Symbolics.COM>
I see no reason to require evaluation order of arguments when there is
already a mechanism to enforce it: use LET* where evaluation order is
important. A good compiler should be able to optimize away the implied
temporaries when the expressed evaluation order matches the
implementation evaluation order.
Remember that Common Lisp is a language with side-effects, and in such
languages there are more constraints on evaluation order than just the
data dependencies. With LET* you are talking data dependencies.
In any case, Scott Fahlman explained quite clearly in an earlier message
why Common Lisp takes the stand it does. I think that reasoning is just
as true today as it was three years ago.
∂21-May-87 1411 larus%paris.Berkeley.EDU@Berkeley.EDU Re: Order of evaluation in PUSH (& PUSHNEW)
Received: from [128.32.150.46] by SAIL.STANFORD.EDU with TCP; 21 May 87 14:11:15 PDT
Received: by paris.Berkeley.EDU (5.57/1.25)
id AA25054; Thu, 21 May 87 14:08:44 PDT
From: larus%paris.Berkeley.EDU@berkeley.edu (James Larus)
Message-Id: <8705212108.AA25054@paris.Berkeley.EDU>
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: P. T. Withington <PTW@yukon.scrc.symbolics.com>,
Scott E. Fahlman <Fahlman@c.cs.cmu.edu>, quiroz@cs.rochester.edu,
common-lisp@sail.stanford.edu
Subject: Re: Order of evaluation in PUSH (& PUSHNEW)
In-Reply-To: Your message of Thu, 21 May 87 16:42:00 EDT.
<870521164208.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 21 May 87 14:08:36 PDT
Date: Thu, 21 May 87 14:19 EDT
From: P. T. Withington <PTW@YUKON.SCRC.Symbolics.COM>
I see no reason to require evaluation order of arguments when there is
already a mechanism to enforce it: use LET* where evaluation order is
important. A good compiler should be able to optimize away the implied
temporaries when the expressed evaluation order matches the
implementation evaluation order.
Remember that Common Lisp is a language with side-effects, and in such
languages there are more constraints on evaluation order than just the
data dependencies. With LET* you are talking data dependencies.
In discussing side-effects between the evaluation of formal arguments,
we are also talking about data-dependencies. Taking a page from the
vector processor and multiprocessor compiler literature: a data-dependence
between two statements occurs when one statement writes a value into a
location and another statement either reads or writes this location.
This gives us three types of data-dependencies: W(rite) followed by
R(read), R followed by W, and W followed by W.
Moon is expressing the common belief that all data-dependencies are of
the first type, as for example:
(LET* ((A (FOO))
(B (BAR A))) ...)
in which the first clause of the LET* statement writes a value into
the location called `a' and the second reads the same location (W-R
for short).
However, there is no fundamental difference between this example and
the following one (R-W):
(REORDER-AND-DIE ARG (SETQ ARG 1))
The major difference between the two is that a larger group of people
would probably object to the latter example on grounds of taste.
In any case, Scott Fahlman explained quite clearly in an earlier message
why Common Lisp takes the stand it does. I think that reasoning is just
as true today as it was three years ago.
As I tried to suggest in my earlier note, there are strong reasons
apart from multiprocessor Lisps why Common Lisp's stand is an
unnecessary constraint on the language.
The status quo be better defended on two grounds: I like side-effects
and want predictability without having to introduce additional
sequence constraints like LET* and PROGN or this is a major change
that will break a lot of code. Multiprocessors are just a
red-herring.
/Jim
∂22-May-87 0152 Randy%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: Order of evaluation in general
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87 01:52:18 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 May 87 04:50-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43818; 22 May 87 04:52:54-EDT
Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 70302; Fri 22-May-87 02:56:02-EDT
Date: Fri, 22 May 87 02:55 EDT
From: Randy%acorn@oak.lcs.mit.edu
To: common-lisp@sail.stanford.edu
Subject: Re: Order of evaluation in general
From: larus%paris.Berkeley.EDU@berkeley.edu (James Larus)
Date: Thu, 21 May 87 09:43:16 PDT
Leaving the order of evaluation of actual parameters unspecified (a la
Scheme) would help some serial, as well as parallel, implementations.
...
I realize that it was explicitly stated (somewhere) that Common
Lisp is ignoring issues of parallelism. Given that parellel is
going to be the next fad, it's probably time to start thinking about
parallel issues. In addition to special forms like PROGN-IN-ANY-ORDER
(or some more aesthetic name), there should be versions of DO-family
and MAP-family functions that could frotz with order however they
wanted.
Random
∂22-May-87 0718 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Order of evaluation in general
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 May 87 07:18:14 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 84675; Fri 22-May-87 10:17:45 EDT
Date: Fri, 22 May 87 10:17 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Order of evaluation in general
To: Randy%acorn@oak.lcs.mit.edu, common-lisp@sail.stanford.edu
In-Reply-To: The message of 22 May 87 02:55 EDT from Randy%acorn@oak.lcs.mit.edu
Message-ID: <870522101716.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Fri, 22 May 87 02:55 EDT
From: Randy%acorn@oak.lcs.mit.edu
I realize that it was explicitly stated (somewhere) that Common
Lisp is ignoring issues of parallelism. Given that parellel is
going to be the next fad, it's probably time to start thinking about
parallel issues.
It's certainly time for many people and many groups to be thinking about
parallel issues, and many are. But I don't think X3J13 is the right
forum for that. Standardization is a very different activity from
language exploration and design. Imposing the constraints of the former
on the latter would be a mistake. It's not time yet to standardize on
parallelism in Lisp; it's time to try things out and gain experience.
That can be done best the way Lisp has always grown: experimentation in
environments that encourage creativity and freedom, rather than the
practical constraints of ANSI standardization.
∂22-May-87 0729 gls@Think.COM All arrays can be adjustable?
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 May 87 07:29:17 PDT
Received: from boethius by Think.COM via CHAOS; Fri, 22 May 87 10:28:41 EDT
Date: Fri, 22 May 87 10:26 EDT
From: Guy Steele <gls@Think.COM>
Subject: All arrays can be adjustable?
To: DFM%JASPER@live-oak.lcs.mit.edu, edsel!bhopal!jonl@navajo.stanford.edu
Cc: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu,
navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
common-lisp@sail.stanford.edu
In-Reply-To: <870521152017.2.DFM@WHITBY.PALLADIAN.COM>
Message-Id: <870522102614.1.GLS@BOETHIUS.THINK.COM>
Date: Thu, 21 May 87 15:20 EDT
From: Don Morrison <dfm@jasper.palladian.com>
Date: Wed, 20 May 87 22:45:04 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
See CLtL page 34 where simple-array is defined as a subtype of array.
Note also that everywhere "subtype" is used, it means "proper subtype".
CLtL, page 33: "If x is a supertype of y, then any object of type y is also of type x,
and y is said to be a subtype of x." Doesn't sound like "proper subtype" to me.
Also, in both Symbolics and Lucid, (subtypep x x) => t for every type I tried.
CLTL page 72: "This predicate [subtypep] is true if type1 is a (not
necessarily proper) subtype of type2."
--Guy
∂22-May-87 0748 gls@Think.COM Re: More FORMAT
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 May 87 07:48:04 PDT
Received: from boethius by Think.COM via CHAOS; Fri, 22 May 87 10:49:17 EDT
Date: Fri, 22 May 87 10:46 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: More FORMAT
To: berman@vaxa.isi.edu, DFM%JASPER@live-oak.lcs.mit.edu
Cc: common-lisp@sail.stanford.edu, gls@think.com
In-Reply-To: <8705201855.AA02717@vaxa.isi.edu>
Message-Id: <870522104659.2.GLS@BOETHIUS.THINK.COM>
Date: Wed, 20 May 87 11:55:34 PDT
From: Richard Berman <berman@vaxa.isi.edu>
As someone else mentioned, it can be more than useful to know that something
is causing an array to grow. It seems reduntant to me to have an :adjustable
keyword if there are no clear semantics to :adjustable nil, only to
:adjustable T. Especially when :adjustable (non-nil) == :adjustable nil.
Or perhaps we need a :non-adjustable keyword, just to keep our semantics
consistent, where :non-adjustable T means "definitely" non-adjustable, and
:non-adjustable nil means "maybe non-adjustable"?
RB
It is not redundant. It is, however, in some sense merely an
efficiency hint. :ADJUSTABLE NIL is a promise on the part of the
programmer never to try to adjust the array. The value of this
promise is that the implementation may then be able to create
an array that uses less time or space.
--Guy
∂22-May-87 0801 gls@Think.COM numerals, Roman, large, overly, printing of, how to do it
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 May 87 08:00:50 PDT
Received: from boethius by Think.COM via CHAOS; Fri, 22 May 87 10:58:47 EDT
Date: Fri, 22 May 87 10:55 EDT
From: Guy Steele <gls@Think.COM>
Subject: numerals, Roman, large, overly, printing of, how to do it
To: berman@vaxa.isi.edu, las@bfly-vax.bbn.com
Cc: common-lisp@sail.stanford.edu, gls@think.com
In-Reply-To: <8705201905.AA02808@vaxa.isi.edu>
Message-Id: <870522105532.3.GLS@BOETHIUS.THINK.COM>
Date: Wed, 20 May 87 12:05:53 PDT
From: Richard Berman <berman@vaxa.isi.edu>
My only question re: roman numerals is: what does *common lisp* do for values
above the specified range (or unspecified, so far as the spec is concerned).
Do we just not print romans above certain values? What is printed instead?
Etc.?
RB
Implementors are informally encouraged to print either the decimal
equivalent, or else the phrase
GUIDO CANTABRIGIENSIS PERDITOR PERDELIRUS
--Quux
∂22-May-87 0815 FAHLMAN@C.CS.CMU.EDU numerals, Roman, large, overly, printing of, how to do it
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87 08:14:57 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 22 May 87 11:14:30-EDT
Date: Fri, 22 May 1987 11:14 EDT
Message-ID: <FAHLMAN.12304419394.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@THINK.COM>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: numerals, Roman, large, overly, printing of, how to do it
In-reply-to: Msg of 22 May 1987 10:55-EDT from Guy Steele <gls at Think.COM>
Implementors are informally encouraged to print either the decimal
equivalent, or else the phrase
GUIDO CANTABRIGIENSIS PERDITOR PERDELIRUS
OK, somebody has to ask: What, O mighty and imponederable Quux, does
this phrase mean in English, if indeed it is translatable and not too
obscene for transmission via netmail?
My Latin stopped with "Sic Friat Crustulum": So crumbles the cookie.
(Actually, I think it's "biscuit" -- the Romans seem not have had
cookies in the modern sense, since Cortes had not yet conquered the land
where chocolate chips grow.)
-- Scott
∂22-May-87 1257 berman@vaxa.isi.edu :KEY, hairsplit
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87 12:56:57 PDT
Posted-Date: Fri, 22 May 87 12:56:46 PDT
Message-Id: <8705221956.AA04810@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA04810; Fri, 22 May 87 12:56:48 PDT
To: common-lisp@sail.stanford.edu
Subject: :KEY, hairsplit
Date: Fri, 22 May 87 12:56:46 PDT
From: Richard Berman <berman@vaxa.isi.edu>
I have an implementation here which interprets the :KEY keyword
of SUBLIS as applying to the ALIST. Consistency seems to demand
that it applies to the TREE. For example, the code for SUBST on
page 274, and the description of :KEY on 246. Nevertheless, with
the description on 246 I couldn't say that they are wrong in applying
it to ALIST:
"If an operation tests elements of a sequence in any manner, the keyword
argument :key, if not nil, should be a function of one argument that will
extract from an element the part to be tested in place of the whole element."
But in SUBLIS, both ALIST and TREE are being "tested". But since it is TREE
that would be affected, and since things like SUBST, SUBSTITUTE and relatives,
all use :key on the effected sequence, it would be inconsistent for :key to
work on ALIST as above. Strictly speaking, I could see how an implementor
could interpret pg 246 to mean applying :key to both ALIST and TREE.
Especially because the only description of :key is in the Sequence chapter,
and despite the fact that :key is used in a number of places in the LISTS
chapter, it is not defined, leaving one with the sequence definition Page 273
says "The naming conventions for these functions and for their keyword
arguments generally follow the conventions for the generic sequence
functions."
Fine.
I am sure most will agree to my interpretation -- That ALIST does not get :key
applied to it, and TREE does. I am trying to convert some of one
manufacturer's tests to the standard format, and ran into this goody.
Any official word?
RB
∂22-May-87 1449 primerd!doug@enx.prime.pdn
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87 14:49:32 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7
id <AA08168@EDDIE.MIT.EDU>; Fri, 22 May 87 17:47:10 EDT
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA16674; Fri, 22 May 87 17:27:10 EDT
Message-Id: <8705222127.AA16674@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 22 May 87 16:34:47 EST
To: COMMON-LISP@SAIL.STANFORD.EDU
From: primerd!DOUG@ENX.Prime.PDN
Date: 22 May 87 16:34:48 EST
To: (common-lisp@sail.stanford.edu)
From: Doug Rand (DOUG@ENX.PRIME.COM)
Date: 22 May 87 4:25 PM
Subject: Portable public domain DEFSYSTEM available for use
I have a defsystem and associated utilities that others may find
useful. I have made the code available for use on SAIL via anonymous
ftp from defsys.lsp[com,lsp] and the documentation from
defsys.doc[com,lsp]. (Many thanks to Dick Gabriel for putting them up
for me)
The usual caveats apply about no warrantty expressed or implied. You
can pass the source and documentation on to others but I ask that
enhancements get funnelled back through me. Modification for your
own use is, of course, no problem.
Some effort has been made in options to use existing names for items
where appropriate but this really isn't a direct copy of the
functionality of the ZETALISP defsystem facility on the LISPM.
Cheers,
Doug
---------------------------
An abbreviated description:
---------------------------
(defsystem system-name
(system-options*)
module-descriptions*
)
Compile-system (function)
(compile-system system-name {keys})
Compiles all modules requiring recompilation. The recompile keyword will
cause all recompilations to occur regardless of 'need'. Need is determined by
the date-time of the respective binary and source files.
(load-system system-name {keys})
Loads modules of a system. Load-system is called recursively for all
required systems. Keyword options are:
(show-system system-name)
Pretty output of system description.
∂22-May-87 1609 DLW@ALDERAAN.SCRC.Symbolics.COM defsystem
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 May 87 16:09:40 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 84991; Fri 22-May-87 19:09:02 EDT
Date: Fri, 22 May 87 19:08 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: defsystem
To: primerd!DOUG@ENX.Prime.PDN, COMMON-LISP@SAIL.STANFORD.EDU
In-Reply-To: <8705222127.AA16674@primerd.prime.com>
Message-ID: <870522190809.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
I thought this would be a nice test case to see how good Common Lisp is
for making portable code, so I tried it out.
It looks as if the function COMPILE-IF-NEEDED needs to have a
declaration, saying (DECLARE (SPECIAL SYSTEM COMPILED-MODULES)) in it,
in order to work properly. Does your CL implementation work without
such a declaration? If so, you might want to check into that, since it
oughtn't, if I'm not mistaken.
It would also be nice to put in (DECLARE (IGNORE LEVEL)) in the
functions PRINT-SYSTEM and PRINT-MODULE, just to suppress the compiler
warnings.
There are a few places that manipulate pathnames by using concatenate to
append a file name to a directory name. That'll work OK with the PRIME
file system (and Symbolics's file system), but it won't with several
others, because syntaxes vary. It should use the pathname manipulation
functions in CL.
I tried running it on a simple case. It signalled an error, trying to
find the file-write-date of a bin file that didn't exist yet, because
the source file (which I had just created) had never been compiled.
This appears to be our bug; file-write-date is supposed to return NIL
"if it cannot be determined". After I fixed this, compile-system,
load-system, and show-system appeared to work properly.
∂25-May-87 0459 GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU All arrays can be adjustable?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 May 87 04:59:23 PDT
Date: Mon 25 May 87 07:58:15-EDT
From: "Gail Zacharias" <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: All arrays can be adjustable?
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12305170113.39.GZ@OZ.AI.MIT.EDU>
The description of ADJUST-ARRAY (bottom of p. 297) says "It is not permitted
to call adjust-array on an array that was not created with the :adjustable
option."
Of course, assuming "not permitted" means "is an error" rather than "signals
an error", an implementation is free to make an extension to CL and have
ADJUST-ARRAY work on some arrays which weren't created with the :ADJUSTABLE
option, and non-portable code is free to take advantage of such an extension.
It seems rather pointless to me, however. Unless the user has detailed
knowledge of exactly which combinations of other arguments to MAKE-ARRAY will
allow ADJUST-ARRAY to work, he has no business trying to adjust an array which
he didn't ask to be adjustable. A friendly implementation would signal an
error, at least when running in a safe mode.
-------
∂25-May-87 1032 primerd!doug@enx.prime.pdn Revision 2.1 of public defsystem available
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 May 87 10:32:31 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7
id <AA19645@EDDIE.MIT.EDU>; Mon, 25 May 87 13:30:19 EDT
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA01965; Mon, 25 May 87 11:28:04 EDT
Message-Id: <8705251528.AA01965@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 25 May 87 11:06:33 EST
Subject: Revision 2.1 of public defsystem available
To: common-lisp@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 25 May 87 11:06:33 EST
There is a new version of defsys available for public ftp from SAIL. This
version has make-pathname instead of concatenate for constructing source and
binary paths and so will work on systems that don't have regularly formed
pathnames. This version should also compile without any errors or warnings.
Cheers,
Doug (doug@enx.prime.com)
∂01-Jun-87 0840 DALY@IBM.COM type specifiers
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87 08:37:05 PDT
Date: 1 June 1987, 11:24:47 EDT
From: Timothy Daly <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <060187.112448.daly@ibm.com>
Subject: type specifiers
CLtL states that
(SIMPLE-VECTOR *) is an abbreviation for (VECTOR T *)
except that the elements are of type simple vector (p47)
CLtL states that
If a type specifier is a list, the car of the list is a symbol
and the rest of the list is subsidiary type information. ... (p42)
CLtL state that
As a convenience, if a list has one or more unspecified items
at the end, such items may simply be dropped rather than writing
an explicit * for each one. (p43)
Is (SIMPLE-VECTOR T) valid? (semantics: (SIMPLE-VECTOR T *))
tim
DALY@IBM.COM
∂01-Jun-87 1929 RWK@YUKON.SCRC.Symbolics.COM type specifiers
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 19:28:51 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 217124; Mon 1-Jun-87 22:12:56 EDT
Date: Mon, 1 Jun 87 22:12 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: type specifiers
To: Timothy Daly <DALY@ibm.com>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <060187.112448.daly@ibm.com>
Message-ID: <870601221248.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: 1 June 1987, 11:24:47 EDT
From: Timothy Daly <DALY@ibm.com>
CLtL states that
(SIMPLE-VECTOR *) is an abbreviation for (VECTOR T *)
except that the elements are of type simple vector (p47)
[This doesn't relate to your question, but...]
A serious bit of miswording, that. It should have said
"except that it additionally specifies that OBJECTS OF THE
TYPE are @I(simple) arrays." I don't have a current list
of corrections to the manual; is this on it already?
CLtL states that
If a type specifier is a list, the car of the list is a symbol
and the rest of the list is subsidiary type information. ... (p42)
[I'm not sure how this part relates to your question.]
CLtL state that
As a convenience, if a list has one or more unspecified items
at the end, such items may simply be dropped rather than writing
an explicit * for each one. (p43)
Is (SIMPLE-VECTOR T) valid? (semantics: (SIMPLE-VECTOR T *))
No. I don't know why you thought it might, so I'm not sure this is
the most helpful answer, but I think p47 is pretty clear that SIMPLE-VECTOR
takes only a single argument, a size. I.e. (SIMPLE-VECTOR 47) =
(SIMPLE-ARRAY T 47).
However, I think this is really also a bug in the manual, and that it is
SUPPOSED to take two arguments, like you apparently thought, and it was
accidentally edited to take arguments like SIMPLE-STRING instead of
SIMPLE-ARRAY. Unfortunately, we've been using the manual to specify the
language, and at this point I think this would have to be regarded as
an incompatible change. (I still think we should fix it; SIMPLE-VECTOR
is of much less use as currently defined, and quite confusing).
If we fix it as described, then the answer to your question is YES.
tim
DALY@IBM.COM
∂03-Jun-87 0739 Mailer@XX.LCS.MIT.EDU SIMPLE-VECTOR
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 07:39:40 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 3 Jun 87 10:38-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 45438; 3 Jun 87 10:23:47-EDT
Received: from DWORKIN.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 1187; 2 Jun 87 21:55:44-EDT
Date: Tue, 2 Jun 87 21:54 EDT
From: Glenn S. Burke <gsb@JASPER.PALLADIAN.COM>
Subject: SIMPLE-VECTOR
To: RWK@YUKON.SCRC.Symbolics.COM, DALY@ibm.com
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870601221248.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870602215436.6.GSB@DWORKIN.PALLADIAN.COM>
Reply-To: Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>
Date: Mon, 1 Jun 87 22:12 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Date: 1 June 1987, 11:24:47 EDT
From: Timothy Daly <DALY@ibm.com>
. . .
Is (SIMPLE-VECTOR T) valid? (semantics: (SIMPLE-VECTOR T *))
No. I don't know why you thought it might, so I'm not sure this is
the most helpful answer, but I think p47 is pretty clear that SIMPLE-VECTOR
takes only a single argument, a size. I.e. (SIMPLE-VECTOR 47) =
(SIMPLE-ARRAY T 47).
However, I think this is really also a bug in the manual, and that it is
SUPPOSED to take two arguments, like you apparently thought, and it was
accidentally edited to take arguments like SIMPLE-STRING instead of
SIMPLE-ARRAY. Unfortunately, we've been using the manual to specify the
language, and at this point I think this would have to be regarded as
an incompatible change. (I still think we should fix it; SIMPLE-VECTOR
is of much less use as currently defined, and quite confusing).
If we fix it as described, then the answer to your question is YES.
Historically, SIMPLE-VECTOR is a contraction of SIMPLE-GENERAL-VECTOR, i.e.
(SIMPLE-ARRAY T (*)) -- it IS intentionally like SIMPLE-STRING. The name got
contracted because many got bent out of shape by the length of SIMPLE-GENERAL-VECTOR,
and I guess no one argued (strongly enough?) against the inconsistent nomenclature.
I think this has caused enough confusion to require attention and an eventual change,
but I am against any reinterpretation of the meaning in the current CL incarnation.
Without looking, i would bet that the only inconsistency is in the name itself, and
the manual is fairly clear on what it means.
∂03-Jun-87 1004 gls@Think.COM Latin
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 10:04:20 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 13:06:50 EDT
Date: Wed, 3 Jun 87 13:04 EDT
From: Guy Steele <gls@Think.COM>
Subject: Latin
To: common-lisp@sail.stanford.edu
Cc: gls@think.com
Message-Id: <870603130434.8.GLS@BOETHIUS.THINK.COM>
Date: Fri, 22 May 1987 11:14 EDT
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Implementors are informally encouraged to print either the decimal
equivalent, or else the phrase
GUIDO CANTABRIGIENSIS PERDITOR PERDELIRUS
OK, somebody has to ask: What, O mighty and imponederable Quux, does
this phrase mean in English, if indeed it is translatable and not too
obscene for transmission via netmail?
How does "Guy of Cambridge, that brain-damaged loser" grab you?
∂03-Jun-87 1505 RWK@YUKON.SCRC.Symbolics.COM SIMPLE-VECTOR
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87 15:05:25 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 218481; Wed 3-Jun-87 18:03:12 EDT
Date: Wed, 3 Jun 87 18:03 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: SIMPLE-VECTOR
To: Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>
cc: DALY@ibm.com, common-lisp@sail.stanford.edu
In-Reply-To: <870602215436.6.GSB@DWORKIN.PALLADIAN.COM>
Message-ID: <870603180301.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Tue, 2 Jun 87 21:54 EDT
From: Glenn S. Burke <gsb@JASPER.PALLADIAN.COM>
Historically, SIMPLE-VECTOR is a contraction of SIMPLE-GENERAL-VECTOR, i.e.
(SIMPLE-ARRAY T (*)) -- it IS intentionally like SIMPLE-STRING. The name got
contracted because many got bent out of shape by the length of SIMPLE-GENERAL-VECTOR,
and I guess no one argued (strongly enough?) against the inconsistent nomenclature.
I was just guessing, since I didn't pay attention when this was discussed.
I think this has caused enough confusion to require attention and an eventual change,
but I am against any reinterpretation of the meaning in the current CL incarnation.
Without looking, i would bet that the only inconsistency is in the name itself, and
the manual is fairly clear on what it means.
Right, I believe the manual is consistant. Perhaps the cleanup to be done
here is to note (in the next printing of the manual?) that the terminology is
is inconsistant.
Unfortunately, leaving it inconsistant means this highly-specific and less
useful thing is taking up the obvious name for a less-specific and more
flexible and useful thing. What would one call this more useful thing?
SIMPLE-VECTOR-MAYBE-NOT-GENERAL? SIMPLE-VECTOR-SPECIALIZED?
SIMPLE-VECTOR-TWO-ARGUMENTS?
∂03-Jun-87 1856 Moon@STONY-BROOK.SCRC.Symbolics.COM SIMPLE-VECTOR
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87 18:56:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 163443; Wed 3-Jun-87 21:55:02 EDT
Date: Wed, 3 Jun 87 21:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SIMPLE-VECTOR
To: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
cc: Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>, DALY@ibm.com, common-lisp@sail.stanford.edu
In-Reply-To: <870603180301.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870603215451.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 3 Jun 87 18:03 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Date: Tue, 2 Jun 87 21:54 EDT
From: Glenn S. Burke <gsb@JASPER.PALLADIAN.COM>
Historically, SIMPLE-VECTOR is a contraction of SIMPLE-GENERAL-VECTOR
....this highly-specific and less
useful thing is taking up the obvious name for a less-specific and more
flexible and useful thing. What would one call this more useful thing?
SIMPLE-VECTOR-MAYBE-NOT-GENERAL? SIMPLE-VECTOR-SPECIALIZED?
SIMPLE-VECTOR-TWO-ARGUMENTS?
(SIMPLE-ARRAY * 1). I don't think we need to add even more names for
subtypes of ARRAY to Common Lisp; there are already too many.
I of course would prefer to remove the whole concept of "simple arrays" from
Common Lisp. But it's certainly not my decision.
∂04-Jun-87 0802 RAM@C.CS.CMU.EDU SIMPLE-VECTOR
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Jun 87 08:02:08 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 4 Jun 87 10:59:34-EDT
Date: Thu, 4 Jun 1987 10:59 EDT
Message-ID: <RAM.12307824544.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
Cc: common-lisp@SAIL.STANFORD.EDU, DALY@IBM.COM,
"Glenn S. Burke" <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>
Subject: SIMPLE-VECTOR
In-reply-to: Msg of 3 Jun 1987 18:03-EDT from Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>
SIMPLE-VECTOR started out meaning "one dimensional simple array" with
exactly the syntax you suggest, and it was changed to the current
semantics. I believe this was because Moon argued that that
interpretation of simple-vector is fairly useless, at least without an
element type being specified. Since under that interpretation, SVREF
is useless, it made sense to flush the bletcherous SGVREF and make
SVREF do that useful thing. I believe that the SIMPLE-ARRAY type was
introduced at the same time.
Note that the old SIMPLE-VECTOR can easily be defined using
SIMPLE-ARRAY:
(deftype rwk-array (&optional type size)
`(simple-array ,type (,size)))
Rob
∂04-Jun-87 1425 RWK@ELEPHANT-BUTTE.SCRC.Symbolics.COM SIMPLE-VECTOR
Received: from ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87 14:25:10 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 181251; Thu 4-Jun-87 17:11:57 EDT
Date: Thu, 4 Jun 87 17:12 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: SIMPLE-VECTOR
To: Ram@C.CS.CMU.EDU
cc: common-lisp@SAIL.STANFORD.EDU, DALY@IBM.COM, Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>
In-Reply-To: <RAM.12307824544.BABYL@>
Message-ID: <870604171246.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 4 Jun 1987 10:59 EDT
From: Ram@C.CS.CMU.EDU
Note that the old SIMPLE-VECTOR can easily be defined using
SIMPLE-ARRAY:
(deftype rwk-array (&optional type size)
`(simple-array ,type (,size)))
Certainly. My only concern is that I don't think RWK-ARRAY
is quite the right name. There's no issue here larger than
what name to attach to which concept. It doesn't seem worth
the energy it will take to do anything about it.
∂04-Jun-87 2350 @Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com Interpretation Needed for #+feature
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jun 87 23:50:29 PDT
Received: from MCC.COM by SU-SCORE.ARPA with TCP; Thu 4 Jun 87 09:26:19-PDT
Received: from pp.mcc.com by MCC.COM with TCP; Thu 4 Jun 87 11:23:55-CDT
Posted-Date: Thursday, 4 June 1987, 11:23-CDT
Message-Id: <8706041624.AA15436@pp.mcc.com>
Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA70505)
id AA15436; Thu, 4 Jun 87 11:24:14 cdt
Date: Thursday, 4 June 1987, 11:23-CDT
From: <krall%pp.mcc.com%pp.mcc.com@mcc.com>
Sender: krall%pp.mcc.com@mcc.com
Subject: Interpretation Needed for #+feature
To: common-lisp@SAIL.STANFORD.EDU
On some systems (LMI Lambda, KCL) the form below is NOT read (or, at least,
I get no complaint):
#+symbolics (local-symbolics-package:name a b c)
On Golden Common Lisp, however, the reader balks because it cannot resolve
local-symbolics-package:name since the package does not exist.
Naturally, I prefer the first behavior for writing code to be moved to
many different machines. What is the correct interpretation?
-Ed Krall
Parallel Processing Program
Microelectronics and Computer Technology Corporation
3500 West Balcones Center Drive
Austin, Texas 78759
(512) 338-3406
ARPA: krall@mcc.com
UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall
∂05-Jun-87 0734 samalone@ATHENA.MIT.EDU Re: Interpretation Needed for #+feature
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 07:34:35 PDT
Received: by ATHENA (5.45/4.7)
id AA03976; Fri, 5 Jun 87 10:35:33 EDT
From: <samalone@ATHENA.MIT.EDU>
Received: by HADES.MIT.EDU (5.45/4.7) id AA16032; Fri, 5 Jun 87 10:31:50 EDT
Message-Id: <8706051431.AA16032@HADES.MIT.EDU>
To: common-lisp@sail.stanford.edu
Subject: Re: Interpretation Needed for #+feature
Date: Fri, 05 Jun 87 10:31:49 EDT
One of the many unimplemented features of Golden Common Lisp is
*READ-SUPPRESS*, which is why GCLisp does the wrong thing with #+ and #-.
(See page 345 of CLtL.)
I have successfully gotten around the problem by redefining the #+ and #-
reader macros to do the following instead of binding *READ-SUPPRESS*:
Copy the current readtable and save it.
Modify the entry for #\: to make it behave the same as #\A.
Read the suppressed form.
Restore the old readtable.
Even this is not easy because, although GCLisp has readtables, it is missing
the standard readtable functions. Send me mail if you need help.
--Stuart A. Malone
∂05-Jun-87 1017 sandra%orion@cs.utah.edu historical question about CASE
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 10:17:49 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA22787; Fri, 5 Jun 87 11:19:24 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA26939; Fri, 5 Jun 87 11:19:20 MDT
Date: Fri, 5 Jun 87 11:19:20 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8706051719.AA26939@orion.utah.edu>
Subject: historical question about CASE
To: common-lisp@sail.stanford.edu
While porting some code between CL implementations, I got bit by the fine
print in the manual about how NIL was not allowed as a singleton key in
CASE, as it could be confused with an empty key list. It's easy enough
to wrap a pair of parentheses around the NIL, but I got to thinking that
an empty key list is not very interesting anyway. Does anyone remember why
it was decided to treat NIL as a list instead of a symbol in this context?
Just curious,
-Sandra
-------
∂05-Jun-87 1019 RPG JIS LISP WG of this year
Received: from utokyo-relay by RELAY.CS.NET id ab00570; 5 Jun 87 3:03 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA17054; Fri, 5 Jun 87 15:26:01 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA17711; Fri, 5 Jun 87 15:23:12+0900
Date: Fri, 5 Jun 87 15:23:12+0900
From: a37078%tansei.cc.u-tokyo.junet@utokyo-relay.csnet (Masayuki Ida)
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706050623.AA17711@tansei.cc.u-tokyo.junet>
To: fahlman@c.cs.cmu.edu, gls@think.com,
ida%tansei.cc.u-tokyo.junet@utokyo-relay.csnet, mathis@ada20.isi.edu,
rpg@su-ai.arpa
Subject: JIS LISP WG of this year
Dear Sirs,
The JIS LISP WG of 1986 was finished March 3rd.
To organize the JIS LISP WG of 1987, we had a preparatory meeting on May 29 Fri.
On the meeting, we welcomed the new chair from Tohoku-university.
His name is Prof. T. Itoh.
He is, I think, about 50 years old and a full professor.
I hope he can settle the matter.
I am a member of the WG.
But the rest of the membership is still misty.
There are still hot debate on the starring.
The meeting of May 29 itself could not enter technical issues.
I feel our JIS situation is the prelude to ISO situation.
MITI person suggested the possibility of the joint effort with ANSI,
but as we had no request from US, his suggestion was not fully understood
by the attendant.
May God Bless us.
Masayuki Ida
∂05-Jun-87 1020 RPG Re: JIS LISP WG of this year
∂05-Jun-87 0443 MATHIS@ADA20.ISI.EDU Re: JIS LISP WG of this year
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 04:43:05 PDT
Date: 5 Jun 1987 04:40-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: JIS LISP WG of this year
From: MATHIS@ADA20.ISI.EDU
To: a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Cc: fahlman@C.CS.CMU.EDU, gls@THINK.COM
Cc: rpg@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jun-87 04:40:08.MATHIS>
In-Reply-To: <8706050623.AA17711@tansei.cc.u-tokyo.junet>
Masayuki,
You mentioned a "nonexistent" request from ANSI. ANSI is very
hard to get to do anything; but know that you have a standing
offer from X3J13 for any kind of reasonable cooperation. As
Chairman of that committee, I can act on this matter in the
absence of ANSI direction to the contrary. If all that sounds
backward, remember this is a nation of lawyers. As Lispers lets
get together.
Bob
∂05-Jun-87 1142 barmar@Think.COM historical question about CASE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 11:42:34 PDT
Received: from occam by Think.COM via CHAOS; Fri, 5 Jun 87 14:44:06 EDT
Date: Fri, 5 Jun 87 14:41 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: historical question about CASE
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8706051719.AA26939@orion.utah.edu>
Message-Id: <870605144148.3.BARMAR@OCCAM.THINK.COM>
Date: Fri, 5 Jun 87 11:19:20 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
While porting some code between CL implementations, I got bit by the fine
print in the manual about how NIL was not allowed as a singleton key in
CASE, as it could be confused with an empty key list. It's easy enough
to wrap a pair of parentheses around the NIL, but I got to thinking that
an empty key list is not very interesting anyway. Does anyone remember why
it was decided to treat NIL as a list instead of a symbol in this context?
Just curious,
-Sandra
-------
I don't remember specifically, but I would guess that it is for the
benefit of macros that take a lists of things and turn them into case
clauses. For example:
(defmacro do-something (thing &key allow-list ignore-list complain-list)
`(case ,thing
(,allow-list (frob-thing ,thing))
(,ignore-list nil)
(,complain-list (error "I won't frob ~S!" ,thing))))
By the way, this is probably a good time to remind people that if they
write macros that make a case clause out of each element of a list, they
should always make them be lists of one element, not singleton keys.
Here's a trivial example:
(defmacro my-case (object &rest clauses)
"Like CASE, but only takes singleton keys."
`(case .,(loop for (key . consequent) in clauses ;I know it isn't CL LOOP
collect `((,key) .,consequent))))
barmar
∂05-Jun-87 1313 SOLEY@XX.LCS.MIT.EDU historical question about CASE
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 13:12:44 PDT
Date: Fri, 5 Jun 1987 16:11 EDT
Message-ID: <SOLEY.12308143452.BABYL@XX.LCS.MIT.EDU>
From: SOLEY@XX.LCS.MIT.EDU
To: Barry Margolin <barmar@THINK.COM>
Cc: common-lisp@SAIL.STANFORD.EDU,
Sandra J Loosemore <sandra%orion@CS.UTAH.EDU>
Subject: historical question about CASE
In-reply-to: Msg of 5 Jun 1987 14:41-EDT from Barry Margolin <barmar at Think.COM>
Date: Friday, 5 June 1987 14:41-EDT
From: Barry Margolin <barmar at Think.COM>
To: Sandra J Loosemore <sandra%orion at cs.utah.edu>
Date: Fri, 5 Jun 87 11:19:20 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
While porting some code between CL implementations, I got bit . . .
Does anyone remember why it was decided to treat NIL as a list
instead of a symbol in this context?
I don't remember specifically, but I would guess that it is for the
benefit of macros that take a lists of things and turn them into case
clauses. For example:
(defmacro do-something (thing &key allow-list ignore-list complain-list)
`(case ,thing
(,allow-list (frob-thing ,thing))
(,ignore-list nil)
(,complain-list (error "I won't frob ~S!" ,thing))))
Silly Programmer, hacks are for kids. That's no reason.
(defmacro do-something (thing &key allow-list ignore-list complain-list)
(append `(case ,thing)
(if allow-list `((,allow-list (frob-thing ,thing))))
.. etc ..
))
-- Richard
∂05-Jun-87 1400 gls@Think.COM historical question about CASE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 13:59:51 PDT
Received: from boethius by Think.COM via CHAOS; Fri, 5 Jun 87 17:01:16 EDT
Date: Fri, 5 Jun 87 16:59 EDT
From: Guy Steele <gls@Think.COM>
Subject: historical question about CASE
To: SOLEY@xx.lcs.mit.edu, barmar@think.com
Cc: common-lisp@sail.stanford.edu, sandra%orion@cs.utah.edu, gls@think.com
In-Reply-To: <SOLEY.12308143452.BABYL@XX.LCS.MIT.EDU>
Message-Id: <870605165904.4.GLS@BOETHIUS.THINK.COM>
Date: Fri, 5 Jun 1987 16:11 EDT
From: SOLEY@xx.lcs.mit.edu
Date: Friday, 5 June 1987 14:41-EDT
From: Barry Margolin <barmar at Think.COM>
To: Sandra J Loosemore <sandra%orion at cs.utah.edu>
Date: Fri, 5 Jun 87 11:19:20 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
While porting some code between CL implementations, I got bit . . .
Does anyone remember why it was decided to treat NIL as a list
instead of a symbol in this context?
I don't remember specifically, but I would guess that it is for the
benefit of macros that take a lists of things and turn them into case
clauses. For example:
(defmacro do-something (thing &key allow-list ignore-list complain-list)
`(case ,thing
(,allow-list (frob-thing ,thing))
(,ignore-list nil)
(,complain-list (error "I won't frob ~S!" ,thing))))
Silly Programmer, hacks are for kids. That's no reason.
(defmacro do-something (thing &key allow-list ignore-list complain-list)
(append `(case ,thing)
(if allow-list `((,allow-list (frob-thing ,thing))))
.. etc ..
))
-- Richard
Why APPEND? What's wrong with this:
(defmacro do-something (thing &key allow-list ignore-list complain-list)
`(case ,thing
,@(when allow-list `((,allow-list (frob-thing ,thing))))
,@(when ignore-list `((,ignore-list nil)))
,@(when complain-list `((,complain-list (error "I won't frob ~S!" ,thing))))))
I use the idiom ",@(when foo `(...baz...))" a LOT.
But indeed, perhaps () as a case item should not have been made
to mean an empty list. But it's probably too late now.
--Guy
∂05-Jun-87 1400 barmar@Think.COM historical question about CASE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 13:59:51 PDT
Received: from occam by Think.COM via CHAOS; Fri, 5 Jun 87 17:01:33 EDT
Date: Fri, 5 Jun 87 16:59 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: historical question about CASE
To: SOLEY@xx.lcs.mit.edu
Cc: common-lisp@sail.stanford.edu,
Sandra J Loosemore <sandra%orion@cs.utah.edu>
In-Reply-To: <SOLEY.12308143452.BABYL@XX.LCS.MIT.EDU>
Message-Id: <870605165918.7.BARMAR@OCCAM.THINK.COM>
Date: Fri, 5 Jun 1987 16:11 EDT
From: SOLEY@xx.lcs.mit.edu
(defmacro do-something (thing &key allow-list ignore-list complain-list)
`(case ,thing
(,allow-list (frob-thing ,thing))
(,ignore-list nil)
(,complain-list (error "I won't frob ~S!" ,thing))))
Silly Programmer, hacks are for kids. That's no reason.
(defmacro do-something (thing &key allow-list ignore-list complain-list)
(append `(case ,thing)
(if allow-list `((,allow-list (frob-thing ,thing))))
.. etc ..
))
I don't know about you, but I find mine much easier to read.
barmar
∂10-Jun-87 0755 dml@NADC.ARPA Common LISP omissions: Collect, Locatives
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 07:55:21 PDT
Received: by NADC.ARPA (5.51/1.0 )
id AA08852; Wed, 10 Jun 87 10:53:14 EDT
Date: Wed, 10 Jun 87 10:53:14 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8706101453.AA08852@NADC.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Common LISP omissions: Collect, Locatives
Cc: dml@NADC.ARPA, silbert@NADC.ARPA
We have been using Common LISP and have noticed two
important omissions in the language.
1) Locatives ("LOCF" as found in ZetaLISP).
2) A COLLECT macro.
A primary reason for locatives would be to create your own
"hash-on-eq" functions. Common LISP provides SXHASH which
hashes on equal. A serious problem occurs if the keys are
circular objects.
A collect macro would allow the construction of lists
maintaining the order of creation. Currently, the only way
to produce the same effect, would be to use PUSH and the
NREVERSE. If the programmer intends to use the partially
constructed list, it would need to be REVERSEd each time.
An example of the collection macro could look like:
(DEFMACRO With-Collection (vars &body body)
(LET (collects gensym)
(DOLIST (var vars)
(SETQ gensym (GENSYM var))
(PUSH gensym (GET var :collect))
(PUSH gensym collects))
(PROG1
`(LET (,@vars ,@collects)
,@(Macroexpand-All body))
(DOLIST (var vars) (POP (GET var :collect)))))
)
(DEFMACRO Collect (obj place)
(LET ((endptr (CAR (GET place :collect))))
`(COND
(,place (SETF (CDR ,endptr) (NCONS ,obj))
(SETQ ,endptr (CDR ,endptr)))
(T (SETQ ,place (NCONS ,obj))
(SETQ ,endptr ,place))))
)
(DEFUN Macroexpand-All (form &AUX (mac (MACROEXPAND form)))
(IF (CONSP form)
(CONS (Macroexpand-All (CAR mac)) (Macroexpand-All (CDR mac)))
mac))
It would be easier to implement the collect macro if a
function like LOCF existed. Furthermore, we would not need
to check the partially constructed list each time to
determine whether it was still empty (see the COND in
#'Collect).
ZetaLISP's LOOP macro includes the collect facility, but
collection should be possible outside of a loop (for
example, when searching through a graph).
David Loewenstern
Mark Silbert
Naval Air Development Center, code 7013
Warminster, PA 18974
<dml@nadc.arpa>
<silbert@nadc.arpa>
∂10-Jun-87 0837 FAHLMAN@C.CS.CMU.EDU Common LISP omissions: Collect, Locatives
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87 08:37:04 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 10 Jun 87 11:35:55-EDT
Date: Wed, 10 Jun 1987 11:35 EDT
Message-ID: <FAHLMAN.12309404026.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: dml@λnadc.arpa (D. Loewenstern)λ
Cc: common-lisp@SAIL.STANFORD.EDU, silbert@NADC.ARPA
Subject: Common LISP omissions: Collect, Locatives
In-reply-to: Msg of 10 Jun 1987 10:53-EDT from dml at nadc.arpa (D. Loewenstern)
We considered adding locatives early in the original design process, but
decided that they didn't make much sense except on machines with
hardware support for forwarding pointers. Lisp machines can use
locatives to implement other Common Lisp constructs, but we felt that it
would be confusing to users and something of a performance trap to make
them part of the portable language, that also has to run well on stock
hardware.
As for collect, when something can be written without any special
problems in the existing language, our strategy has been to add it to
the standard only if (1) a LOT of people would otherwise end up coding
this hack for themselves and (2) a single built-in version would satisfy
all of those users. If that kind of need can be demonstrated for
COLLECT, it should go in; if not, it should be added to the
public-domain library for those people who do want it.
Most of the critics of Common Lisp feel that we have put in too many of
these optional things already.
-- Scott
∂10-Jun-87 1101 hoey@nrl-aic.ARPA LISP:STRUCTURE ?
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 11:01:39 PDT
Return-Path: <hoey@nrl-aic.ARPA>
Received: Wed, 10 Jun 87 13:59:26 edt by nrl-aic.ARPA id AA29108
Date: 10 Jun 1987 12:43:18 EDT (Wed)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: LISP:STRUCTURE ?
To: common-lisp@sail.stanford.edu
Message-Id: <550341798/hoey@nrl-aic>
1. Is there a symbol named "STRUCTURE" in the LISP package? In all the
``official'' lists I have seen, the symbol appears. Yet I find no
mention of it in CLtL nor in the lists of errata.
2. In the Common Lisps I have been able to test, LISP:STRUCTURE names a
type of which types defined by DEFSTRUCT are subtypes. Is STRUCTURE a
standard type that should be added to table 4-1?
3. If the answer to 1 is yes, and the answer to 2 is no, then what is
LISP:STRUCTURE for?
Dan
∂10-Jun-87 1120 RAM@C.CS.CMU.EDU LISP:STRUCTURE ?
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87 11:20:40 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 10 Jun 87 14:17:47-EDT
Date: Wed, 10 Jun 1987 14:17 EDT
Message-ID: <RAM.12309433493.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Dan Hoey <hoey@NRL-AIC.ARPA>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: LISP:STRUCTURE ?
In-reply-to: Msg of 10 Jun 1987 12:43-EDT from Dan Hoey <hoey at nrl-aic.ARPA>
STRUCTURE is a documentation type: see the DOCUMENTATION function. I
believe you are right that STRUCTURE is not a Common Lisp type
specifier.
Rob
∂10-Jun-87 1121 KMP@STONY-BROOK.SCRC.Symbolics.COM LISP:STRUCTURE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 11:21:14 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169440; Wed 10-Jun-87 14:18:48 EDT
Date: Wed, 10 Jun 87 14:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: LISP:STRUCTURE
To: hoey@nrl-aic.ARPA
cc: Common-Lisp@SAIL.STANFORD.EDU
In-Reply-To: <550341798/hoey@nrl-aic>
Message-ID: <870610141846.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
See p440. STRUCTURE is a valid second argument to DOCUMENTATION and by
implication must be on the LISP package. As with VARIABLE, it is not a type.
∂10-Jun-87 1238 DALY@IBM.COM locatives...
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87 12:37:53 PDT
Date: 10 June 1987, 15:13:19 EDT
From: Timothy Daly <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <061087.151319.daly@ibm.com>
Subject: locatives...
Re: locatives
We also have felt the need to do hashing-on-eq type of operations.
That is, we would like to be able to hash a pair consisting
of (address of left subtree . address of right subtree).
Unfortunately, SXHASH will walk both subtrees which is much
too expensive. We could think of no portable way to implement
this in common lisp. Since the language gives us no way to
implement this it does not seem that locatives are a frill.
tim
DALY@IBM.COM
T.J.Watson Research, Yorktown.
∂10-Jun-87 1415 Moon@VALLECITO.SCRC.Symbolics.COM Common LISP omissions: Locatives
Received: from SCRC-VALLECITO.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 14:15:12 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 131870; Wed 10-Jun-87 17:09:32 EDT
Date: Wed, 10 Jun 87 17:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Common LISP omissions: Locatives
To: David Loewenstern <dml@NADC.ARPA>, Mark Silbert <silbert@NADC.ARPA>,
Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, Timothy Daly <DALY@ibm.com>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8706101453.AA08852@NADC.ARPA>,
<FAHLMAN.12309404026.BABYL@C.CS.CMU.EDU>,
<061087.151319.daly@ibm.com>
Message-ID: <870610170743.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 10 Jun 87 10:53:14 EDT
From: dml@nadc.arpa (D. Loewenstern)
We have been using Common LISP and have noticed two
important omissions in the language.
1) Locatives ("LOCF" as found in ZetaLISP).
2) A COLLECT macro.
[I won't address COLLECT in this particular message]
A primary reason for locatives would be to create your own
"hash-on-eq" functions. Common LISP provides SXHASH which
hashes on equal. A serious problem occurs if the keys are
circular objects.
Locatives have no relevance to hashing on EQ. The Zetalisp feature you
are thinking of is %POINTER, not LOCF. %POINTER is a function that
returns a number which is the address of its argument. LOCF is a macro
that returns a locative that designates the cell that is designated by
the generalized variable (in the SETF sense) that is LOCF's first
subform. The possible operations on locatives are getting the contents
of the cell, changing the contents of the cell, making the cell
"unbound", checking whether the cell is "unbound", comparing two
locatives for equality, and recovering the object that contains the cell.
It's pretty easy to make your own variant of SXHASH that detects
circularities, although it's bound to be a little slower. I believe
the IBM VM/LISP people published a paper on this a while back.
Date: 10 June 1987, 15:13:19 EDT
From: Timothy Daly <DALY@ibm.com>
We also have felt the need to do hashing-on-eq type of operations.
That is, we would like to be able to hash a pair consisting
of (address of left subtree . address of right subtree).
Unfortunately, SXHASH will walk both subtrees which is much
too expensive. We could think of no portable way to implement
this in common lisp. Since the language gives us no way to
implement this it does not seem that locatives are a frill.
There -is- no portable way to implement hashing-on-eq efficiently,
because it is inherently dependent on the implementation details of the
system's garbage collector. For example, in many systems a garbage
collection changes the numerical value of the addresses of objects. In
these systems, anything that depends on the numerical values of
addresses of objects has to be recomputed after a garbage collection.
It's difficult to come up with a portable and efficient way of doing
that, particularly in systems with multiple levels of garbage
collection, which several systems do in somewhat different ways. It's
even harder to do it in a way that doesn't impose an efficiency burden
on systems where garbage collection does not change the numerical values
of object addresses. This is why Common Lisp did not attempt to provide
a hash-on-eq primitive, that is, a function that returns a number given
an object, without looking at the contents of the object, and always
returns the same number for the same object.
There is a portable -inefficient- way to implement hashing-on-eq, which
is to use a hash table :test #'eq to remember what hash code you have
assigned to each object. I have actually used this. However, this is
usually too inefficient to be seriously considered.
Date: Wed, 10 Jun 1987 11:35 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
We considered adding locatives early in the original design process, but
decided that they didn't make much sense except on machines with
hardware support for forwarding pointers.
Locatives have no relevance to forwarding pointers, nor do they have any
relevance to hardware support.
However, I agree that locatives should not be in Common Lisp. My reason
is that only some of the possible Lisp implementation techniques for
object representation permit the efficient implementation of locatives.
It is always possible to implement locatives, as T has demonstrated, but
it isn't always possible to implement them efficiently. It seems
inappropriate to design the language in a way that would rule out some
otherwise reasonable implementation techniques (BIBOP, for example).
∂11-Jun-87 1313 gls@Think.COM Re: historical question about CASE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 13:13:27 PDT
Received: from boethius by Think.COM via CHAOS; Thu, 11 Jun 87 16:15:05 EDT
Date: Thu, 11 Jun 87 16:12 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: historical question about CASE
To: FREEMAN@sumex-aim.stanford.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <12309682881.14.FREEMAN@SUMEX-AIM.STANFORD.EDU>
Message-Id: <870611161254.3.GLS@BOETHIUS.THINK.COM>
Date: Thu, 11 Jun 87 10:07:37 PDT
From: Andy Freeman <FREEMAN@sumex-aim.stanford.edu>
You wrote:
I use the idiom ",@(when foo `(...baz...))" a LOT.
I thought that it was considered poor style to use "when" for its
value. I may be confusing my dialects, but is there actually a
guarantee that "when"'s definition is much like following?
(defmacro when (pred &body x)
`(if , pred (progn '() ,@ x)
'()))
Yes, there is such a guarantee: the second sentence of the
description of WHEN in CLTL, page 115. (Did you look there?)
I agree that in this case I am not consistent; strictly speaking
perhaps AND is more appropriate, but I find WHEN mnemonically
more appealing in this context, and there is no question that
the value is being used, because of the presence of ",@" right
before the form.
--Guy
∂12-Jun-87 1022 dml@NADC.ARPA Hash-on-eq
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 12 Jun 87 10:22:02 PDT
Received: by NADC.ARPA (5.51/1.0 )
id AA22156; Fri, 12 Jun 87 13:20:34 EDT
Date: Fri, 12 Jun 87 13:20:34 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8706121720.AA22156@NADC.ARPA>
To: daly@ibm.com
Subject: Hash-on-eq
Cc: common-lisp@sail.stanford.edu
We have implemented a portable, efficient method for performing hash-on-
eq upon structures:
1. Set up a global counter.
2. For each key structure that will be hashed, add an extra slot.
3. Each time a key structure is instantiated, the current value of the
global counter is incremented and stored in the extra slot.
4. Instead of using SXHASH upon the key structure, use the accessor
function to get the value in the extra slot.
As an added feature, this method will produce nearly uniform hash table
distributions. At the expense of introducing an extra slot per structure, you
gain a very fast hashing function.
David Loewenstern & Mark Silbert
<dml@nadc.arpa, silbert@nadc.arpa>
∂22-Jun-87 0422 fritzson@bigburd.PRC.Unisys.COM APPLY with 3+ arguments
Received: from BIGBURD.PRC.UNISYS.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 04:21:55 PDT
Received: from bigburd.PRC.Unisys.COM by burdvax.PRC.Unisys.COM (burdvax) [5.54/1.0]
id AA01279; Mon, 22 Jun 87 07:21:34 EDT
Received: by bigburd.PRC.Unisys.COM (bigburd) [5.54/1.0]
id AA16283; Mon, 22 Jun 87 07:21:31 EDT
From: Richard Fritzson <fritzson@bigburd.PRC.Unisys.COM>
Message-Id: <8706221121.AA16283@bigburd.PRC.Unisys.COM>
Received: from Plebian by bigburd with PUP; Mon, 22 Jun 87 07:21 EDT
Date: 22 Jun 87 07:19 EDT (Monday)
To: common-lisp@sail.stanford.edu
Subject: APPLY with 3+ arguments
Can anyone provide a motivation for the CLtL definition of APPLY when
more than one arglist is provided? I understand what it does perfectly
well, but I don't understand when I am going to have a use for this.
-Rich Fritzson
ARPA: fritzson@prc.unisys.com
UUCP: {seismo,sdcrdcf,psuvax1}!burdvax!fritzson
∂22-Jun-87 0601 dml@NADC.ARPA Re: APPLY with 3+ arguments
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 22 Jun 87 06:01:23 PDT
Received: by NADC.ARPA (5.51/1.0 )
id AA03305; Mon, 22 Jun 87 09:01:16 EDT
Date: Mon, 22 Jun 87 09:01:16 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8706221301.AA03305@NADC.ARPA>
To: common-lisp@sail.stanford.edu, fritzson@bigburd.prc.unisys.com
Subject: Re: APPLY with 3+ arguments
I use 3+ arguments for APPLY often. Usually, I use this when the first few arguments to a function
are known, but the remainder are to be passed in as a list:
(APPLY #'MAX 0 list) == find the MAX of a list, but return 0 if all elements of the list are negative.
Naturally, this isn't strictly necessary -- you could write the above as:
(MAX 0 (APPLY #'MAX list))
but I find the first preferable.
David Loewenstern
Naval Air Development Center
code 7013
Warminster, PA 18974-5000
<dml@nadc.arpa>
∂22-Jun-87 0654 @RELAY.CS.NET:kers@HPLB.CSNET I Like a Single Namespace
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 22 Jun 87 06:53:56 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa13493; 22 Jun 87 9:19 EDT
Received: from hplb by RELAY.CS.NET id aa10406; 22 Jun 87 9:10 EDT
From: Christopher Dollin <kers%hplb.csnet@RELAY.CS.NET>
Date: Mon, 22 Jun 87 13:53:15 GMT
Message-Id: <25156.8706221353@hplb.lb.hp.co.uk>
To: common-lisp@SAIL.STANFORD.EDU
Subject: I Like a Single Namespace
Issues in Function and Value Cells
------ -- -------- --- ----- -----
I have been reading "Issues of Separation in Function Cells and Value Cells"
and would like to add some comments. It is interesting to compare the choices
discussed in the paper, and taken in Common Lisp, with similar choices in the
language Pop11 (as instantiated in Poplog Version 11 onwards).
Pop is a good language for comparison purposes, as it falls into the same
general class as Lisp: imperative, interactive (and incremental), dynamically
typed, extensible. (In contrast to Lisp, it is compile-only, has orthodox
syntax, uses an open stack, and does not unite the notions of list and
program. But these are separate issues.)
Pop has (shallow) dynamic binding and (full) lexical binding, with variables
having only one value cell. In practice there does not seem to be any
particular problem with local names shadowing global ones (since Pop11 is
intended as, amongst other things, a teaching language, this is a significant
point). Why is this?
Partly because of the names of the built-in procedures. Some of them, such as
the underlying primitive "sysconslist", have names a user (especially a
beginner!) would be unlikely to choose. Some of them have such common and
well-entrenched meanings that it doesn't occur to anyone that they might use
them as variables (eg, "hd", the approximate equivalent of "car"). Many of
them are spelt with sign characters, eg the list brackets "[" and "]", the
append operator "<>"; it is less natural to use names like this for ordinary
variables, especially for programmers originally trained in Pascal or C,
where the set of infix operators is not extensible.
The other reason is that those names are "protected"; they cannot be
redeclared or assigned to. Hence one learns rapidly which names are acceptable
and which are not; there are only a few names one misses being able to use
("in" and "to" are the ones that come to mind, and I once made the mistake of
reserving "a"). Experienced users can unprotect - and protect - names if they
so desire.
What about efficiency? Since there is only one value namespace, mustn't every
call be checked to ensure it is a procedure object being applied? In general,
yes.
The first observation is that Pop programs run "fast enough", so clearly the
inefficency induced by checking calls of every user procedure is not that
high. The second is that the only sort of type declaration supported (at
present) by the underlying implementation is that of declaring a variable to
be of type procedure, in which case only procedure values can be stored into
it and calls can be compiled as direct jumps rather than going through
"apply".
Variables can also be declared as "constant", permitting the compiler to avoid
generating additional indirections in the code (this is true for values other
than procedures as well, of course). Many system procedures are "protected
constant procedure"s. (As it happens, they are also not garbage-collected, and
have absolute addresses, but that's a separate issue).
What have we demonstrated? That, by example, the single namespace is workable,
and the possible disadvantages of efficiency and name clashes are countered by
declarations (a device Common Lisp already supports) and name protection (a
natural device that Common Lisp omits).
Another point worthy of note is the way Pop treats variable declarations. When
a variable is declared, it is annotated as being dynamic ("vars") or lexical
("lvars"). The declaration masks any that would be inherited from an outer
scope. Unlike Common Lisp, variables can be declared lexical at the "top
level" of a compilation (interaction) too: in this case they are local to the
current compilation and are inaccessible from outside it. This turns out to be
very convenient, permitting modules to be defined which expose only a few
names to the outside world, while having many names internally, without having
to use the Pop "section" mechanism (roughly equivalent to Lisp packages, but
with a different set of design mistakes).
Pop distinguishes "dynamic" constants (which are dynamic variables with fixed
values) from "lexical" constants; just as with variables, lexical constants
are visible only within a single compilation unit. Although it is possible to
change a dynamic constant (by re-declaring it; of course all existing
references will still get the old constant, so this facility is primarily
useful when re-loading code when a change has been made) a lexical constant
cannot be redefined.
Naturally procedure names may be defined as being in any of the four classes
"vars", "lvars", "constant", or "lconstant"; this is done with the simple
expedient of allowing one of these words to follow the introductory "define"
of the declaration.
A very interesting difference between Lisp's and Pop's treatment of local
declarations of dynamic variables is the way the dyamic variable is rebound
when the binding procedure is entered - it isnt. The variable continues to
have its existing value until an assignment to it is made; the only effect of
the local redefinition is to ensure that its OLD value will be restored on
procedure exit. This turns out to be useful behaviour, eg for locally
incrementing a counter, or locally augmenting a procedure. For example, in a
simple popup menu procedure which paints its picture inside an editor buffer,
I have a declaration rather like
vars interrupt = restore_the_screen <> interrupt;
"interrupt" is called when an error occurs, and "<>" will compose procedures
as well as append lists (and vectors). This declaration will temporarily
change interrupt so that it will restore the screen before doing whatever it
used to do; note that for this to work it is ESSENTIAL that the old value of
interrupt be available. Another useful definition is
vars popliblist = my_library :: popliblist;
within a library-searching procedure to augment the library list "popliblist"
with ones own library; again, it is essential that the old value of the
dynamic variable be available. Without this one has to restore to
unwind-protects or double declarations as in
(let ((old-special-variable special-variable))
(let ((special-variable expression-involving-old-special-variable))
bit-that-does-the-work
)
)
where the unholy conspiracy between the structure of let-bindings and the
behaviour of dynamic binding leaves a lot to be desired, especially if more
than one special variable is being so modified.
What is the conclusion here? That a sensible and useful meaning can be found
for top-level lexical bindings ("global" bindings in the terms of the paper),
and that a useful alternative definition for local dynamic variable
declarations can be found and is used in an existing language.
A local guru tells me that I can be contacted at
kers%hplb.csnet@csnet-relay.arpa
which is my address at HPLabs Bristol.
Kers
∂22-Jun-87 0655 samalone@ATHENA.MIT.EDU Re: APPLY with 3+ arguments
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jun 87 06:55:17 PDT
Received: by ATHENA.MIT.EDU (5.45/4.7)
id AA04179; Mon, 22 Jun 87 09:57:07 EDT
From: <samalone@ATHENA.MIT.EDU>
Received: by HADES.MIT.EDU (5.45/4.7) id AA02757; Mon, 22 Jun 87 09:51:48 EDT
Message-Id: <8706221351.AA02757@HADES.MIT.EDU>
To: common-lisp@sail.stanford.edu
Subject: Re: APPLY with 3+ arguments
Date: Mon, 22 Jun 87 09:51:46 EDT
Can anyone provide a motivation for the CLtL definition of
APPLY when more than one arglist is provided? I understand
what it does perfectly well, but I don't understand when I am
going to have a use for this.
Another use is to write functions like the following:
(defun simplify (new old sequence &rest keyword-args)
(apply #'remove-duplicates
(apply #'substitute new old sequence :count 1 keyword-args)
keyword-args))
If APPLY took only two arguments it would be necessary for this function to
either take explicit keywords itself or splice the :count keyword/value pair
into the argument list for SUBSTITUTE manually. (BTW: Adding keyword arguments
in this way is well-defined -- see pg. 62 of CLtL.)
--Stuart A. Malone
∂22-Jun-87 0741 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM APPLY with 3+ arguments
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 22 Jun 87 07:40:58 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98345; Mon 22-Jun-87 10:15:32 EDT
Date: Mon, 22 Jun 87 10:14 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: APPLY with 3+ arguments
To: Richard Fritzson <fritzson@bigburd.PRC.Unisys.COM>, common-lisp@sail.stanford.edu
In-Reply-To: <8706221121.AA16283@bigburd.PRC.Unisys.COM>
Message-ID: <870622101406.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: 22 Jun 87 07:19 EDT (Monday)
From: Richard Fritzson <fritzson@bigburd.PRC.Unisys.COM>
Can anyone provide a motivation for the CLtL definition of APPLY when
more than one arglist is provided? I understand what it does perfectly
well, but I don't understand when I am going to have a use for this.
There are two common uses I have seen. One is to have a function take
an &REST arg which is the arguments for some other function, yet the
middle-man wants to supply additional keywords or override them, such as
(defun make-raster-bit-array (width height &rest other-make-array-args)
(apply #'make-array (list height width) :element-type 'bit
other-make-array-args))
The other common case is similar, but is used to supply required
and optional arguments to a function which also takes an &REST arg, for
example,
(defun trace-format (format-string &rest format-args)
(apply #'format *trace-output* format-string format-args))
∂22-Jun-87 0959 barmar@Think.COM I Like a Single Namespace
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 09:59:25 PDT
Received: from occam by Think.COM via CHAOS; Mon, 22 Jun 87 13:01:49 EDT
Date: Mon, 22 Jun 87 12:59 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: I Like a Single Namespace
To: Christopher Dollin <kers%hplb.csnet@relay.cs.net>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <25156.8706221353@hplb.lb.hp.co.uk>
Message-Id: <870622125923.6.BARMAR@OCCAM.THINK.COM>
Date: Mon, 22 Jun 87 13:53:15 GMT
From: Christopher Dollin <kers%hplb.csnet@relay.cs.net>
Issues in Function and Value Cells
------ -- -------- --- ----- -----
[...]
Without this one has to restore to
unwind-protects or double declarations as in
(let ((old-special-variable special-variable))
(let ((special-variable expression-involving-old-special-variable))
bit-that-does-the-work
)
)
where the unholy conspiracy between the structure of let-bindings and the
behaviour of dynamic binding leaves a lot to be desired, especially if more
than one special variable is being so modified.
The above is not necessary in any Maclisp-descended Lisp I'm familiar
with.
(let ((*special-var* *special-var*))
bit-that-does-the-work)
works fine (and is used quite often) in Maclisp, Zetalisp, and Common
Lisp. The expressions in a LET value form are evaluated in the dynamic
environment OUTSIDE the LET. You may be confusing this with the fact
that declarations at the beginning of a LET body refer to variables in
the value forms; this means that you can't do
(let ((*special-var* *special-var*))
(declare (unspecial *special-var*))
bit-that-does-the-work)
and have the lexical *SPECIAL-VAR* get initialized from the dynamic
*SPECIAL-VAR*.
barmar
∂22-Jun-87 1359 Daniels.pa@Xerox.COM Re: APPLY with 3+ arguments
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 13:59:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 87 12:10:23 PDT
Date: 22 Jun 87 12:09 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: APPLY with 3+ arguments
In-reply-to: Richard Fritzson <fritzson@bigburd.PRC.Unisys.COM>'s
message of 22 Jun 87 07:19 EDT (Monday)
To: fritzson@bigburd.PRC.Unisys.COM
cc: common-lisp@sail.stanford.edu
Message-ID: <870622-121023-1188@Xerox>
Perhaps you're a little confused about how APPLY with more than 2 args
works. Only the last argument passed to APPLY is an arglist. The rest
are individual arguments to the applied function. As CLtL says, "it is
as if all the arguments to apply execpt the function were given to LIST*
to create the argumentlist."
Thus (APPLY #'LIST '(1 2) '(3 4)) => ((1 2) 3 4), not (1 2 3 4). Page
108 of CLtL and the other replies to your message give reasonable
examples of what you can use this for.
-- Andy. --
∂22-Jun-87 1457 Daniels.pa@Xerox.COM Re: APPLY with 3+ arguments
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 13:59:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 87 12:10:23 PDT
Date: 22 Jun 87 12:09 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: APPLY with 3+ arguments
In-reply-to: Richard Fritzson <fritzson@bigburd.PRC.Unisys.COM>'s
message of 22 Jun 87 07:19 EDT (Monday)
To: fritzson@bigburd.PRC.Unisys.COM
cc: common-lisp@sail.stanford.edu
Message-ID: <870622-121023-1188@Xerox>
Perhaps you're a little confused about how APPLY with more than 2 args
works. Only the last argument passed to APPLY is an arglist. The rest
are individual arguments to the applied function. As CLtL says, "it is
as if all the arguments to apply execpt the function were given to LIST*
to create the argumentlist."
Thus (APPLY #'LIST '(1 2) '(3 4)) => ((1 2) 3 4), not (1 2 3 4). Page
108 of CLtL and the other replies to your message give reasonable
examples of what you can use this for.
-- Andy. --
∂23-Jun-87 0252 @RELAY.CS.NET:kers@HPLB.CSNET
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Jun 87 02:52:14 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa22002; 23 Jun 87 4:19 EDT
Received: from hplb by RELAY.CS.NET id ab04330; 23 Jun 87 4:11 EDT
From: Christopher Dollin <kers%hplb.csnet@RELAY.CS.NET>
Date: Tue, 23 Jun 87 08:22:01 GMT
Message-Id: <1977.8706230822@hplb.lb.hp.co.uk>
To: common-lisp@SAIL.STANFORD.EDU
Oops!
Yes, I guess I slipped. Using LET* will cover the case of multiple
bindings, too. Must have been a bad day ... can't even blame jet-lag ...
Regards,
Kers
(Using KMail 10-Apr-87 (Kers))
∂23-Jun-87 0654 CL.BOYER@R20.UTEXAS.EDU Kyoto Common Lisp
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87 06:54:29 PDT
Date: Mon 22 Jun 87 20:24:22-CDT
From: CL.BOYER@R20.UTEXAS.EDU
Subject: Kyoto Common Lisp
To: ailist@STRIPE.SRI.COM, common-lisp@SAIL.STANFORD.EDU,
arpanet-bboards@MC.LCS.MIT.EDU
Message-ID: <12312656894.9.CL.BOYER@R20.UTEXAS.EDU>
Kyoto Common Lisp (KCL) is a complete implementation of Common Lisp written
by T. Yuasa and M. Hagiya working under Professor R. Nakajima at the
Research Institute for Mathematical Sciences, Kyoto University. It runs on
many different machines and is highly portable. It executes very
efficiently and it is superbly documented. KCL is being made available at
no fee through the implementors' generosity. The complete sources are
included. One channel of distribution is via ftp on the Arpanet/Internet.
LICENSE REQUIRED!
IMPORTANT: Although there is no fee, KCL is not in the public domain. You
are authorized to obtain it only after signing and mailing in a license
agreement. Before you ftp KCL files you MUST fill out and send in the
license agreement included in this message. Otherwise, you are not
permitted to make copies of KCL.
COPYING KCL VIA INTERNET
KCL may be obtained from Internet source rascal.ics.utexas.edu [128.83.144.1],
a Sun-3 at the University of Texas at Austin. To obtain KCL, login as "ftp"
with password "guest". There are three tar files:
/pub/kcl.tar, 4.0 megabytes
/pub/kcl.tar.C, produced by compact from kcl.tar, 2.8 megabytes
/pub/kcl.tar.Z, produced by compress from kcl.tar, 1.2 megabytes
Any of the three files is sufficient to generate KCL. Please ftp the
compressed file if possible. Please use ftp at an odd hour if possible to
reduce traffic on a sometimes heavily loaded network. Be sure to use binary
mode with ftp. A current version of this message may be found as the file
/pub/kcl.broadcast.
MACHINES ON WHICH KCL RUNS
KCL runs on many machines. With the sources provided in the ftp file, KCL
may be executed on the following machines (and operating systems).
VAX/UNIX (4.2BSD)
SUN2 (OS2, 3) SUN3 (OS3)
SONY'S NEWS (4.2BSD)
ATT3B2 (System V)
Fujitu S3000 (System V)
Sumitomo's E15 (Uniplus System V)
Data General MV (DGUX)
Instructions for making the system are in the file doc/porting in the ftp
tar file.
KCL LICENSE FORM
To obtain the right to copy KCL, sign this license form and send it and a copy
to the Kyoto address at the end of the form. ONCE YOU HAVE MAILED THE SIGNED
LICENSE FORM, YOU MAY COPY KCL. YOU DO NOT HAVE TO WAIT FOR RECEIPT OF THE
SIGNED FORM.
--------------------------- cut here ----------------------------
!
LICENSE AGREEMENT
FOR
KYOTO COMMON LISP
The Special Interest Group in LISP (Taiichi Yuasa and Masami Hagiya) at the
Research Institute for Mathematical Sciences, Kyoto University (hereinafter
referred to as SIGLISP) grants to
USER NAME: _________________________________________
USER ADDRESS: ______________________________________
______________________________________
(hereinafter referred to as USER), a non-transferable and non-exclusive license
to copy and use Kyoto Common LISP (hereinafter referred to as KCL) under the
following terms and conditions and for the period of time identified in
Paragraph 6.
1. This license agreement grants to the USER the right to use KCL within their
own home or organization. The USER may make copies of KCL for use within their
own home or organization, but may not further distribute KCL except as provided
in paragraph 2.
2. SIGLISP intends that KCL be widely distributed and used, but in a
manner which preserves the quality and integrity of KCL. The USER may send
a copy of KCL to another home or organization only after either receiving
permission from SIGLISP or after seeing written evidence that the other
home or organization has signed this agreement and sent a hard copy of it
to SIGLISP. If the USER has made modifications to KCL and wants to
distribute that modified copy, the USER will first obtain permission from
SIGLISP by written or electronic communication. Any USER which has
received such a modified copy can pass it on as received, but must receive
further permission for further modifications. All modifications to copies
of KCL passed on to other homes or organizations shall be clearly and
conspicuously indicated in all such copies. Under no other circumstances
than provided in this paragraph shall a modified copy of KCL be represented
as KCL.
3. The USER will ensure that all their copies of KCL, whether modified or not,
carry as the first information item the following copyright notice:
(c) Copyright Taiichi Yuasa and Masami Hagiya, 1984. All rights reserved.
Copying of this file is authorized to users who have executed the true and
proper "License Agreement for Kyoto Common LISP" with SIGLISP.
4. Title to and ownership of KCL and its copies shall at all times remain
with SIGLISP and those admitted by SIGLISP as contributors to the
development of KCL. The USER will return to SIGLISP for further
distribution modifications to KCL, modifications being understood to mean
changes which increase the speed, reliability and existing functionality of
the software delivered to the USER. The USER may make for their own
ownership and use enhancements to KCL which add new functionality and
applications which employ KCL. Such modules may be returned to SIGLISP at
the option of the USER.
5. KCL IS LICENSED WITH NO WARRANTY OF ANY KIND. SIGLISP WILL NOT BE
RESPONSIBLE FOR THE CORRECTION OF ANY BUGS OR OTHER DEFICIENCIES. IN NO
EVENT SHALL SIGLISP BE LIABLE FOR ANY DAMAGES OF ANY KIND, INCLUDING
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR IN CONNECTION
WITH THE USE OR PERFORMANCE OF KCL.
6. This license for KCL shall be effective from the date hereof and shall
remain in force until the USER discontinues use of KCL. In the event the USER
neglects or fails to perform or observe any obligations under this Agreement,
this Agreement and the License granted hereunder shall be immediately
terminated and the USER shall certify to SIGLISP in writing that all copies of
KCL in whatever form in its possession or under its control have been
destroyed.
7. Requests. KCL is provided by SIGLISP in a spirit of friendship and
cooperation. SIGLISP asks that people enjoying the use of KCL cooperate in
return to help further develop and distribute KCL. Specifically, SIGLISP
would like to know which machines KCL gets used on. A brief notice form is
appended to this agreement which the user is requested to send by email or
otherwise. Please send in further notifications at reasonable intervals if
you increase the number and type of machines on which KCL is loaded. You
may send these notices to another USER which is cooperating with SIGLISP
for this purpose.
USER
DATE: _________________________________________
BY: ___________________________________________
TITLE: ________________________________________
ADDRESS: ______________________________________
______________________________________
SIGLISP
DATE: _________________________________________
BY: ___________________________________________
Taiichi Yuasa Masami Hagiya
Special Interest Group in LISP
Research Institute for Mathematical Sciences
Kyoto University
Kyoto, 606, JAPAN
Telex: 05422020 RIMS J
JUNET: siglisp@kurims.kurims.kyoto-u.junet
CSNET: siglisp%kurims.kurims.kyoto-u.junet@utokyo-relay.csnet
USER has loaded KCL on the following machines since (date):
Model Number Production Name Number of Machines
!
END OF LICENSE FORM
--------------------------- cut here ------------------------
DOCUMENTATION
The principal documentation for KCL is, of course, the book "Common Lisp
The Language" by Guy L. Steele, Jr. with contributions by Scott E. Fahlman,
Richard P. Gabriel, David A. Moon, and Daniel L. Weinreb, Digital Press,
1984. Implementation-specific details of KCL (debugging, garbage
collection, data structure format, declarations, operating system
interface, installation) may be found in the 131 page "Kyoto Common Lisp
Report" by Taiichi Yuasa and Masami Hagiya, the authors of KCL. This
report is available from:
Teikoku Insatsu Inc.
Shochiku-cho,
Ryogae-cho-dori Takeya-machi Sagaru,
Naka-gyo-ku,
Kyoto, 604, Japan
tel: 075-231-4757
for 5,000 yen plus postage.
The KCL Report is produced by the text-formatter KROFF (Kyoto ROFF), which
is used locally within Kyoto University. Currently KROFF works only on
printers available in Japan. It is possible that an American
distributorship of this report will be arranged. The source of the report,
with KROFF commands, is found in the file doc/report on the ftp tar file.
It is possible to read this source, though it is as hard on the eyes as TeX
or Scribe source. A translation of this source into TeX is underway and
will be available as part of the distribution tape. Future information
about the availability of the KCL Report will be available in updated
versions of this message, in the file /pub/kcl.broadcast.
A document describing how to port KCL to other systems is available at no
charge from the authors of KCL.
Each of the KCL primitives is thoroughly described by the "describe"
function, which is based on 340K bytes of documentation.
SUPPORT
KCL is one of the most bug-free large software systems that we have ever used.
However, when bugs are found, they may be reported to the implementors:
hagiya%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET
yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET
We have found them extremely responsive to bug reports and suggestions.
SAMPLE TRANSCRIPT
Below is a complete transcript for obtaining and installing KCL on a Sun-3.
Make a directory for locating KCL
tutorial% mkdir /usr/joe/kcl
Get the compressed tar file
tutorial% cd /usr/joe/kcl
tutorial% ftp 128.83.144.1
220 rascal FTP server (Version 4.7 Sun Sep 14 12:44:57 PDT 1986) ready.
Name: ftp
Password: guest
ftp>binary
ftp>get /pub/kcl.tar.Z kcl.tar.Z
ftp>quit
Build the KCL directory structure
tutorial% uncompress kcl.tar.Z
tutorial% tar -xvf kcl.tar .
tutorial% rm kcl.tar
Make KCL
tutorial% cd /usr/joe/kcl/
tutorial% su
password: super-user-password
tutorial# cp h/cmpinclude.h /usr/include
tutorial# exit
tutorial% make
Edit and Install Two Files
We wish to replace "~" by "/usr/joe" in lc and kcl, and put
them in a directory on the search path e.g. "/usr/joe/bin"
tutorial% cd /usr/joe/kcl/unixport
tutorial% mkdir /usr/joe/bin
tutorial% sed -e "s.~./usr/joe/kcl.g" lc > /usr/joe/bin/lc
tutorial% sed -e "s.~./usr/joe/kcl.g" kcl > /usr/joe/bin/kcl
tutorial% chmod a+x /usr/joe/bin/lc /usr/joe/bin/kcl
It is now possible to run kcl:
tutorial% /usr/joe/bin/kcl
KCL (Kyoto Common Lisp)
>(+ 2 3)
5
>(bye)
It is best to become super user and execute the following commands, so that all
users may execute kcl.
tutorial% su
Password: superuser-password
tutorial# cp /usr/joe/bin/kcl /usr/local/bin
tutorial# cp /usr/joe/bin/lc /usr/local/bin
tutorial# exit
This transcript puts the entire kcl system, including sources and
documentation, in the directory /usr/joe/kcl. Any other directory name
would do as well, e.g., /usr/local instead of /usr/joe. Although this
transcript has worked perfectly for us on a Sun-3, it might not work for
you if you are running under NFS but not logged into the right machine:
you may need to login as root on the system where /usr/include and
/usr/local/bin are really located to do the super-user things. Immediately
after the make is finished about 8.4 megatyes of disk space are in use.
SINCERELY YOURS
Robert S. Boyer William F. Schelter
cl.boyer@r20.utexas.edu atp.schelter@r20.utexas.edu
This message was written by Robert S. Boyer and William F. Schelter. The
opinions expressed are theirs and are not necessarily those of the authors of
KCL, the University of Texas, or MCC. The authors of KCL have, however,
indicated that they have no objection to our distributing this message.
P.S. Thanks to Dave Capshaw, George Fann, Warren Hunt, Ken Rimey, and Carl
Quillen for helping debug this message. Ken Rimey,
rimey@ernie.Berkeley.EDU, makes the following remarks about bringing up
this release of KCL under BSD 4.3 on a Vax.
1. Bringing up KCL under BSD4.3. The machine on which I installed kcl was
a Vax 88xx running Ultrix V2.0. Kcl crashed when executing the final
save-system command in init_kcl.lsp. It also did so on a Vax running
BSD4.3. (I don't know of any Vaxen still running 4.2.) The problem is
caused by some highly non-portable code introduced into Lsave() in
c/unixsave.c since the version of March 28, 1986. I deleted the new code
and reintroduced the old which had been commented out. Here is the
resulting working Lsave():
Lsave()
{
char filename[256];
check_arg(1);
check_type_or_pathname_string_symbol_stream(&vs_base[0]);
coerce_to_filename(vs_base[0], filename);
_cleanup();
memory_save(kcl_self, filename);
exit(0);
/* no return */
}
KCL ran successfully after only fixing the Lsave problem.
2. The files o/makefile and unixport/makefile define variables that need to be
changed when compiling for any machine other than a Sun-3. These definitions
are found at the heads of these files. Here is the head of my copy of
o/makefile:
MACHINE = VAX
# Select 'VAX', 'SUN', 'SUN2R3', 'SUN3', 'ISI', 'SEQ', 'IBMRT',
# or 'NEWS'.
CHTAB = char_table.s
# Select 'char_table.s' or 'sun_chtab.s'.
# 1) char_table.s : for VAX, SEQ and NEWS
# 2) sun_chtab.s : for SUN, SUN2R3 and SUN3
# 3) isi_chtab.s : for ISI
# 4) ibmrt_chtab.s: for IBMRT
For machines other than Sun-3, one might change the MAKE KCL
section of this message to:
tutorial% cd /usr/joe/kcl/
tutorial% vi o/makefile (If not Sun-3, change definitions MACHINE and CHTAB.)
tutorial% vi o/unixport (If not Sun-3, change definition of MACHINE.)
tutorial% su
password: super-user-password
tutorial# cp h/cmpinclude.h /usr/include
tutorial# exit
tutorial% make
-------
∂23-Jun-87 1535 BAGGINS@IBM.COM A multi-byte character extension proposal
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 23 Jun 87 15:34:22 PDT
Date: Tue, 23 Jun 87 12:54:31 PDT
From: "Thomas Linden (Thom)" <baggins@ibm.com>
To: "Dr. Masayuki Ida"
<a37078%tansei.u-tokyo.junet%utokyo-relay.csnet@relay.cs.net>, Common
Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <870623.125431.baggins@IBM.com>
Subject: A multi-byte character extension proposal
Professor Ida:
We have had the opportunity to review the
English translation of part of the JEIDA proposal
regarding the extension of Common Lisp to large
(multi-byte) character sets. We were impressed with the scope of the
issues addressed. However, the translation was vague on a few points,
and we would like clarification. Your anwsers to the following
questions would be appreciated:
1)
The paper proposes that Lisp characters be assigned unique codes over
a potentially large domain (possibly all the integers between 0 and
65535). Are characters with different codes always syntactically
distinct? Can the standard character #\( have two different codes,
corresponding, for example, to two different external file system
representations of that character? If so, would the Lisp reader
always parse these two representations identically?
2)
CLtL says, (p. 233) "The code attribute is intended to distinguish
among the printed glyphs and formatting functions for characters."
Does the JEIDA proposal permit two different string-chars to have
the same print glyph, '(' for example, but different syntactical
properties?
3)
Under the proposal, it is up to each implementation how it
chooses to translate the contents of files or terminal input when
passed as input to the Lisp system. We have both single-byte and
double-byte character conventions for file contents; thus is it
allowable to map both of these sets of codes into the one,
internal Lisp character code set when inputting data to Lisp, and
adopt our own conventions for translating output back to single
and double byte?
4)
An elaboration of the the previous question: Is it possible for an
implementation to represent all of the standard characters internally
with 2-byte codes, and to map some 2-byte character codes and some
1-byte character codes in system files onto the same set of 2-byte
internal codes for the standard characters when read into Lisp?
5)
The English copy we saw of the proposal did not contain section 4.4.
Based on our own translation from the original in Japanese, this
section seems to discuss implementation issues. Given a system such
as our's, which has both single-byte and double-byte conventions for
some characters, including the Common Lisp standard characters, there
seem to be two possible treatments of double byte characters. The
first is the case where a double-byte character can be a standard
character. The second is where a double-byte character cannot be
a standard character.
5a)
Is the proposal's default, in section 4.4, that a Lisp
implementation reading a file on a system with both single-byte
and double-byte conventions, not recognize any double-byte character
in that file as a standard character?
5b)
There are three example Lisp forms with underlining which seem
to indicate three options of single-byte/double-byte equivalency.
Consider the symbol 'abc' in these forms. Is the difference
between option 1 and option 2 whether the Lisp system would
recognize a single-byte version and a double-byte version
of this symbol-name in the same file as referring to the same
(EQ) symbol?
1. (list abc /fg " xy " )
--------------------------------
2. (list abc /fg " xy " )
-- ---- ----- --- ----
3. (list abc /fg " xy " )
------------------------ -----
5c)
If a Lisp system does not recognize these two symbol names
as equivalent, doesn't that require the Lisp system to have
two characters with different codes but the same print glyph?
5d)
Under the default proposal, if the character object print
syntax "#\a" or "#\A" is read from a file, is alpha-char-p true
1. if the 'a' had been encoded as a single byte?
2. if the 'a' had been encoded as a double byte?
3. if the 'A' had been encoded as a single byte?
4. if the 'A' had been encoded as a double byte?
5e)
Is section 4.4 a part of the proposal to ANSI, or
has it been included for merely illustrative purposes?
If you could elaborate (in English) on the content of section
4.4, we would greatly appreciate it.
6)
Even if the Lisp system supports a large character set, only
standard characters have, as a default, non-constituent syntax
type, constituent character attributes relevant to parsing of numbers
and symbols, or defined syntax within a format control string.
Correct?
7)
If a Lisp system supports a large character code set, need it allow
every character of type string-char to have a non-constituent syntax
type defined in the readtable, or is the proposal's default that
only standard characters need be represented in the readtable?
8)
A specific case related to the previous question: suppose #\% were a
non-standard character, but still a string-char in some implementation
of Lisp. Is
(make-dispatch-macro-character #\%)
necessarily permitted in every implementation that supports #\% as a
string-char?
Regards,
Thom Linden
∂25-Jun-87 0923 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87 09:22:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA24561; Thu, 25 Jun 87 23:49:44 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA15608; Thu, 25 Jun 87 23:48:59+0900
Date: Thu, 25 Jun 87 23:48:59+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re: A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU
Date: Tue, 23 Jun 87 12:54:31 PDT
From: "Thomas Linden (Thom)" <baggins@ibm.com>
1)
Are characters with different codes always syntactically
distinct?
Yes.
Can the standard character #\( have two different codes,
corresponding, for example, to two different external file system
representations of that character?
No.
(because you said 'the standard character'...)
We cannot talk about the different representations on files.
Some implementations may read 'similar' characters into one internal
code, but others may not.
2)
Does the JEIDA proposal permit two different string-chars to have
the same print glyph, '(' for example, but different syntactical
properties?
We did not discuss about the issue related to your question,
because we have no scope on the characters which has the same print glyph but
different syntactical properties.
There are several japanese characters which have similar glyphs.
But their glyphs are not 'the same' (except for blank characters).
3)
Is it
allowable to map both of these sets of codes into the one,
internal Lisp character code set when inputting data to Lisp, and
adopt our own conventions for translating output back to single
and double byte?
yes.
4)
An elaboration of the the previous question: Is it possible for an
implementation to represent all of the standard characters internally
with 2-byte codes, and to map some 2-byte character codes and some
1-byte character codes in system files onto the same set of 2-byte
internal codes for the standard characters when read into Lisp?
yes.
5)
The English copy we saw of the proposal did not contain section 4.4.
Based on our own translation from the original in Japanese, this
section seems to discuss implementation issues.
Since we could not make a good conclusion on the issue,
the section 4.4 of the early draft injapanese was deleted.
The proposal have many freedom for implementors.
there
seem to be two possible treatments of double byte characters. The
first is the case where a double-byte character can be a standard
character. The second is where a double-byte character cannot be
a standard character.
I think so too.
5a)
Implementation dependent.
5b)
Is the difference
between option 1 and option 2 whether the Lisp system would
recognize a single-byte version and a double-byte version
of this symbol-name in the same file as referring to the same
(EQ) symbol?
Yes.
1. (list abc /fg " xy " )
--------------------------------
2. (list abc /fg " xy " )
-- ---- ----- --- ----
3. (list abc /fg " xy " )
------------------------ -----
We tried to select one and only one selection among the above 3 'options'.
But we found we cannot make decision until ISO related standardization
of japanese character representation.
5c)
I cannot understand what you said.
I don't imagine the status like "there is a character which has a same print glyph but different code."
5d)
Implementation dependent.
Standard-character may be single-byte or may be multi-byte,
according to the definition of the implementation.
5e)
Is section 4.4 a part of the proposal to ANSI?
No.
If you could elaborate (in English) on the content of section
4.4, we would greatly appreciate it.
Please ask IBM japan (your subsidiary) for the complex issue
behind the section 4.4 of the early draft in japanese.
We need more observations on other languages, file systems,
operating systems and JIS character set definition refinement
itself before we might make a firm guideline for the matter.
6)
Correct?
Your interpretation can cope with our proposal.
7)
If a Lisp system supports a large character code set, need it allow
every character of type string-char to have a non-constituent syntax
type defined in the readtable, or is the proposal's default that
only standard characters need be represented in the readtable?
CLtL says (22.1.5 page 360):
"every character of type string-char must be represented in the readtable."
The members felt as we extended the definition of string-char to include
japanese characters, as the results of a natual interpretation of CLtL,
the readtable must have more than 64k 'logical' entries.
Regards,
Thom Linden
Masayuki Ida
PS: our proposal is the result of several japanese and USA CL implementations.
Though we will welcome any opinions to our proposal, I feel
the final decision will be by ANSI, JIS, and ISO.
One of the members of our WG will attend the X3J13 meeting, since
I cannot leave my university on the next week.
He is a very active members and he knows the process.
He is scheduled to have a presentation on this issue at the X3J13 meeting.
∂25-Jun-87 1028 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87 09:22:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA24561; Thu, 25 Jun 87 23:49:44 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA15608; Thu, 25 Jun 87 23:48:59+0900
Date: Thu, 25 Jun 87 23:48:59+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re: A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU
Date: Tue, 23 Jun 87 12:54:31 PDT
From: "Thomas Linden (Thom)" <baggins@ibm.com>
1)
Are characters with different codes always syntactically
distinct?
Yes.
Can the standard character #\( have two different codes,
corresponding, for example, to two different external file system
representations of that character?
No.
(because you said 'the standard character'...)
We cannot talk about the different representations on files.
Some implementations may read 'similar' characters into one internal
code, but others may not.
2)
Does the JEIDA proposal permit two different string-chars to have
the same print glyph, '(' for example, but different syntactical
properties?
We did not discuss about the issue related to your question,
because we have no scope on the characters which has the same print glyph but
different syntactical properties.
There are several japanese characters which have similar glyphs.
But their glyphs are not 'the same' (except for blank characters).
3)
Is it
allowable to map both of these sets of codes into the one,
internal Lisp character code set when inputting data to Lisp, and
adopt our own conventions for translating output back to single
and double byte?
yes.
4)
An elaboration of the the previous question: Is it possible for an
implementation to represent all of the standard characters internally
with 2-byte codes, and to map some 2-byte character codes and some
1-byte character codes in system files onto the same set of 2-byte
internal codes for the standard characters when read into Lisp?
yes.
5)
The English copy we saw of the proposal did not contain section 4.4.
Based on our own translation from the original in Japanese, this
section seems to discuss implementation issues.
Since we could not make a good conclusion on the issue,
the section 4.4 of the early draft injapanese was deleted.
The proposal have many freedom for implementors.
there
seem to be two possible treatments of double byte characters. The
first is the case where a double-byte character can be a standard
character. The second is where a double-byte character cannot be
a standard character.
I think so too.
5a)
Implementation dependent.
5b)
Is the difference
between option 1 and option 2 whether the Lisp system would
recognize a single-byte version and a double-byte version
of this symbol-name in the same file as referring to the same
(EQ) symbol?
Yes.
1. (list abc /fg " xy " )
--------------------------------
2. (list abc /fg " xy " )
-- ---- ----- --- ----
3. (list abc /fg " xy " )
------------------------ -----
We tried to select one and only one selection among the above 3 'options'.
But we found we cannot make decision until ISO related standardization
of japanese character representation.
5c)
I cannot understand what you said.
I don't imagine the status like "there is a character which has a same print glyph but different code."
5d)
Implementation dependent.
Standard-character may be single-byte or may be multi-byte,
according to the definition of the implementation.
5e)
Is section 4.4 a part of the proposal to ANSI?
No.
If you could elaborate (in English) on the content of section
4.4, we would greatly appreciate it.
Please ask IBM japan (your subsidiary) for the complex issue
behind the section 4.4 of the early draft in japanese.
We need more observations on other languages, file systems,
operating systems and JIS character set definition refinement
itself before we might make a firm guideline for the matter.
6)
Correct?
Your interpretation can cope with our proposal.
7)
If a Lisp system supports a large character code set, need it allow
every character of type string-char to have a non-constituent syntax
type defined in the readtable, or is the proposal's default that
only standard characters need be represented in the readtable?
CLtL says (22.1.5 page 360):
"every character of type string-char must be represented in the readtable."
The members felt as we extended the definition of string-char to include
japanese characters, as the results of a natual interpretation of CLtL,
the readtable must have more than 64k 'logical' entries.
Regards,
Thom Linden
Masayuki Ida
PS: our proposal is the result of several japanese and USA CL implementations.
Though we will welcome any opinions to our proposal, I feel
the final decision will be by ANSI, JIS, and ISO.
One of the members of our WG will attend the X3J13 meeting, since
I cannot leave my university on the next week.
He is a very active members and he knows the process.
He is scheduled to have a presentation on this issue at the X3J13 meeting.
∂25-Jun-87 1143 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87 09:22:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA24561; Thu, 25 Jun 87 23:49:44 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA15608; Thu, 25 Jun 87 23:48:59+0900
Date: Thu, 25 Jun 87 23:48:59+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re: A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU
Date: Tue, 23 Jun 87 12:54:31 PDT
From: "Thomas Linden (Thom)" <baggins@ibm.com>
1)
Are characters with different codes always syntactically
distinct?
Yes.
Can the standard character #\( have two different codes,
corresponding, for example, to two different external file system
representations of that character?
No.
(because you said 'the standard character'...)
We cannot talk about the different representations on files.
Some implementations may read 'similar' characters into one internal
code, but others may not.
2)
Does the JEIDA proposal permit two different string-chars to have
the same print glyph, '(' for example, but different syntactical
properties?
We did not discuss about the issue related to your question,
because we have no scope on the characters which has the same print glyph but
different syntactical properties.
There are several japanese characters which have similar glyphs.
But their glyphs are not 'the same' (except for blank characters).
3)
Is it
allowable to map both of these sets of codes into the one,
internal Lisp character code set when inputting data to Lisp, and
adopt our own conventions for translating output back to single
and double byte?
yes.
4)
An elaboration of the the previous question: Is it possible for an
implementation to represent all of the standard characters internally
with 2-byte codes, and to map some 2-byte character codes and some
1-byte character codes in system files onto the same set of 2-byte
internal codes for the standard characters when read into Lisp?
yes.
5)
The English copy we saw of the proposal did not contain section 4.4.
Based on our own translation from the original in Japanese, this
section seems to discuss implementation issues.
Since we could not make a good conclusion on the issue,
the section 4.4 of the early draft injapanese was deleted.
The proposal have many freedom for implementors.
there
seem to be two possible treatments of double byte characters. The
first is the case where a double-byte character can be a standard
character. The second is where a double-byte character cannot be
a standard character.
I think so too.
5a)
Implementation dependent.
5b)
Is the difference
between option 1 and option 2 whether the Lisp system would
recognize a single-byte version and a double-byte version
of this symbol-name in the same file as referring to the same
(EQ) symbol?
Yes.
1. (list abc /fg " xy " )
--------------------------------
2. (list abc /fg " xy " )
-- ---- ----- --- ----
3. (list abc /fg " xy " )
------------------------ -----
We tried to select one and only one selection among the above 3 'options'.
But we found we cannot make decision until ISO related standardization
of japanese character representation.
5c)
I cannot understand what you said.
I don't imagine the status like "there is a character which has a same print glyph but different code."
5d)
Implementation dependent.
Standard-character may be single-byte or may be multi-byte,
according to the definition of the implementation.
5e)
Is section 4.4 a part of the proposal to ANSI?
No.
If you could elaborate (in English) on the content of section
4.4, we would greatly appreciate it.
Please ask IBM japan (your subsidiary) for the complex issue
behind the section 4.4 of the early draft in japanese.
We need more observations on other languages, file systems,
operating systems and JIS character set definition refinement
itself before we might make a firm guideline for the matter.
6)
Correct?
Your interpretation can cope with our proposal.
7)
If a Lisp system supports a large character code set, need it allow
every character of type string-char to have a non-constituent syntax
type defined in the readtable, or is the proposal's default that
only standard characters need be represented in the readtable?
CLtL says (22.1.5 page 360):
"every character of type string-char must be represented in the readtable."
The members felt as we extended the definition of string-char to include
japanese characters, as the results of a natual interpretation of CLtL,
the readtable must have more than 64k 'logical' entries.
Regards,
Thom Linden
Masayuki Ida
PS: our proposal is the result of several japanese and USA CL implementations.
Though we will welcome any opinions to our proposal, I feel
the final decision will be by ANSI, JIS, and ISO.
One of the members of our WG will attend the X3J13 meeting, since
I cannot leave my university on the next week.
He is a very active members and he knows the process.
He is scheduled to have a presentation on this issue at the X3J13 meeting.
∂25-Jun-87 1255 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87 09:22:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA24561; Thu, 25 Jun 87 23:49:44 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA15608; Thu, 25 Jun 87 23:48:59+0900
Date: Thu, 25 Jun 87 23:48:59+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re: A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU
Date: Tue, 23 Jun 87 12:54:31 PDT
From: "Thomas Linden (Thom)" <baggins@ibm.com>
1)
Are characters with different codes always syntactically
distinct?
Yes.
Can the standard character #\( have two different codes,
corresponding, for example, to two different external file system
representations of that character?
No.
(because you said 'the standard character'...)
We cannot talk about the different representations on files.
Some implementations may read 'similar' characters into one internal
code, but others may not.
2)
Does the JEIDA proposal permit two different string-chars to have
the same print glyph, '(' for example, but different syntactical
properties?
We did not discuss about the issue related to your question,
because we have no scope on the characters which has the same print glyph but
different syntactical properties.
There are several japanese characters which have similar glyphs.
But their glyphs are not 'the same' (except for blank characters).
3)
Is it
allowable to map both of these sets of codes into the one,
internal Lisp character code set when inputting data to Lisp, and
adopt our own conventions for translating output back to single
and double byte?
yes.
4)
An elaboration of the the previous question: Is it possible for an
implementation to represent all of the standard characters internally
with 2-byte codes, and to map some 2-byte character codes and some
1-byte character codes in system files onto the same set of 2-byte
internal codes for the standard characters when read into Lisp?
yes.
5)
The English copy we saw of the proposal did not contain section 4.4.
Based on our own translation from the original in Japanese, this
section seems to discuss implementation issues.
Since we could not make a good conclusion on the issue,
the section 4.4 of the early draft injapanese was deleted.
The proposal have many freedom for implementors.
there
seem to be two possible treatments of double byte characters. The
first is the case where a double-byte character can be a standard
character. The second is where a double-byte character cannot be
a standard character.
I think so too.
5a)
Implementation dependent.
5b)
Is the difference
between option 1 and option 2 whether the Lisp system would
recognize a single-byte version and a double-byte version
of this symbol-name in the same file as referring to the same
(EQ) symbol?
Yes.
1. (list abc /fg " xy " )
--------------------------------
2. (list abc /fg " xy " )
-- ---- ----- --- ----
3. (list abc /fg " xy " )
------------------------ -----
We tried to select one and only one selection among the above 3 'options'.
But we found we cannot make decision until ISO related standardization
of japanese character representation.
5c)
I cannot understand what you said.
I don't imagine the status like "there is a character which has a same print glyph but different code."
5d)
Implementation dependent.
Standard-character may be single-byte or may be multi-byte,
according to the definition of the implementation.
5e)
Is section 4.4 a part of the proposal to ANSI?
No.
If you could elaborate (in English) on the content of section
4.4, we would greatly appreciate it.
Please ask IBM japan (your subsidiary) for the complex issue
behind the section 4.4 of the early draft in japanese.
We need more observations on other languages, file systems,
operating systems and JIS character set definition refinement
itself before we might make a firm guideline for the matter.
6)
Correct?
Your interpretation can cope with our proposal.
7)
If a Lisp system supports a large character code set, need it allow
every character of type string-char to have a non-constituent syntax
type defined in the readtable, or is the proposal's default that
only standard characters need be represented in the readtable?
CLtL says (22.1.5 page 360):
"every character of type string-char must be represented in the readtable."
The members felt as we extended the definition of string-char to include
japanese characters, as the results of a natual interpretation of CLtL,
the readtable must have more than 64k 'logical' entries.
Regards,
Thom Linden
Masayuki Ida
PS: our proposal is the result of several japanese and USA CL implementations.
Though we will welcome any opinions to our proposal, I feel
the final decision will be by ANSI, JIS, and ISO.
One of the members of our WG will attend the X3J13 meeting, since
I cannot leave my university on the next week.
He is a very active members and he knows the process.
He is scheduled to have a presentation on this issue at the X3J13 meeting.
∂25-Jun-87 1505 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87 09:22:18 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA24561; Thu, 25 Jun 87 23:49:44 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA15608; Thu, 25 Jun 87 23:48:59+0900
Date: Thu, 25 Jun 87 23:48:59+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re: A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU
Date: Tue, 23 Jun 87 12:54:31 PDT
From: "Thomas Linden (Thom)" <baggins@ibm.com>
1)
Are characters with different codes always syntactically
distinct?
Yes.
Can the standard character #\( have two different codes,
corresponding, for example, to two different external file system
representations of that character?
No.
(because you said 'the standard character'...)
We cannot talk about the different representations on files.
Some implementations may read 'similar' characters into one internal
code, but others may not.
2)
Does the JEIDA proposal permit two different string-chars to have
the same print glyph, '(' for example, but different syntactical
properties?
We did not discuss about the issue related to your question,
because we have no scope on the characters which has the same print glyph but
different syntactical properties.
There are several japanese characters which have similar glyphs.
But their glyphs are not 'the same' (except for blank characters).
3)
Is it
allowable to map both of these sets of codes into the one,
internal Lisp character code set when inputting data to Lisp, and
adopt our own conventions for translating output back to single
and double byte?
yes.
4)
An elaboration of the the previous question: Is it possible for an
implementation to represent all of the standard characters internally
with 2-byte codes, and to map some 2-byte character codes and some
1-byte character codes in system files onto the same set of 2-byte
internal codes for the standard characters when read into Lisp?
yes.
5)
The English copy we saw of the proposal did not contain section 4.4.
Based on our own translation from the original in Japanese, this
section seems to discuss implementation issues.
Since we could not make a good conclusion on the issue,
the section 4.4 of the early draft injapanese was deleted.
The proposal have many freedom for implementors.
there
seem to be two possible treatments of double byte characters. The
first is the case where a double-byte character can be a standard
character. The second is where a double-byte character cannot be
a standard character.
I think so too.
5a)
Implementation dependent.
5b)
Is the difference
between option 1 and option 2 whether the Lisp system would
recognize a single-byte version and a double-byte version
of this symbol-name in the same file as referring to the same
(EQ) symbol?
Yes.
1. (list abc /fg " xy " )
--------------------------------
2. (list abc /fg " xy " )
-- ---- ----- --- ----
3. (list abc /fg " xy " )
------------------------ -----
We tried to select one and only one selection among the above 3 'options'.
But we found we cannot make decision until ISO related standardization
of japanese character representation.
5c)
I cannot understand what you said.
I don't imagine the status like "there is a character which has a same print glyph but different code."
5d)
Implementation dependent.
Standard-character may be single-byte or may be multi-byte,
according to the definition of the implementation.
5e)
Is section 4.4 a part of the proposal to ANSI?
No.
If you could elaborate (in English) on the content of section
4.4, we would greatly appreciate it.
Please ask IBM japan (your subsidiary) for the complex issue
behind the section 4.4 of the early draft in japanese.
We need more observations on other languages, file systems,
operating systems and JIS character set definition refinement
itself before we might make a firm guideline for the matter.
6)
Correct?
Your interpretation can cope with our proposal.
7)
If a Lisp system supports a large character code set, need it allow
every character of type string-char to have a non-constituent syntax
type defined in the readtable, or is the proposal's default that
only standard characters need be represented in the readtable?
CLtL says (22.1.5 page 360):
"every character of type string-char must be represented in the readtable."
The members felt as we extended the definition of string-char to include
japanese characters, as the results of a natual interpretation of CLtL,
the readtable must have more than 64k 'logical' entries.
Regards,
Thom Linden
Masayuki Ida
PS: our proposal is the result of several japanese and USA CL implementations.
Though we will welcome any opinions to our proposal, I feel
the final decision will be by ANSI, JIS, and ISO.
One of the members of our WG will attend the X3J13 meeting, since
I cannot leave my university on the next week.
He is a very active members and he knows the process.
He is scheduled to have a presentation on this issue at the X3J13 meeting.
∂25-Jun-87 1626 Cassels@STONY-BROOK.SCRC.Symbolics.COM Format ~E nit -- language lawyer sought
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jun 87 16:25:48 PDT
Received: from KRYPTON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 182534; Thu 25-Jun-87 19:10:35 EDT
Date: Thu, 25 Jun 87 19:10 EDT
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Format ~E nit -- language lawyer sought
To: Common-Lisp@SAIL.Stanford.EDU
Message-ID: <870625191023.3.CASSELS@KRYPTON.SCRC.Symbolics.COM>
What should be the result of (format nil "~E" 1.0)?
A. "1.0e+0"
B. "1.0e0"
C. All of the above
D. None of the above
The top of page 393 says, "Next, either a plus or a minus sign is
printed, followed by e digits ... [decimal exponent]"
Later on page 393 we see, "If all of w, d, and e are omitted, then the
effect is ... [like prin1].
Page 366 [presumably where prin1 is defined] doesn't explicitly say that
the plus sign is omitted from the exponent, but all the examples (and
usual practice) indicate that.
The first reference implies that A is correct, the third reference
implies that B is correct. The second reference implies that A and B
are the same.
∂26-Jun-87 1911 VERACSD@A.ISI.EDU MODIFYF
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Jun 87 19:11:13 PDT
Date: 26 Jun 1987 22:10-EDT
Sender: VERACSD@A.ISI.EDU
Subject: MODIFYF
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: veracsd@A.ISI.EDU
Message-ID: <[A.ISI.EDU]26-Jun-87 22:10:38.VERACSD>
Was the following ever considered for Common Lisp?
After SETF, the most logical and general generalized-variable
function (macro) to have next would clearly seem to be something
I call MODIFYF.
(MODIFYF function place . args)
would be approximately equivalent to
(SETF place (function place . args))
except of course for subforms of place being evaluated only once.
(There are a couple of issues, such as
1) unless you prefer swapping the order of args in MODIFYF,
function being evaluated before place)
2) evaluating function and going to (funcall function place . args) instead,
thus allowing lambdas and suchlike.)
This is reminiscent of, among other things, the op= statements
of the C language, where op includes +, -, etc.
Many (if not all) "modify macros" would be easily defined in terms
of it. E.g.,
(defmacro INCF (place &optional (increment 1))
(MODIFYF + place increment))
When called directly in user code, MODIFYF stands in approximately
the same relation to DEFINE-MODIFY-MACRO as LAMBDA-expressions stand to
DEFUN.
Bob Sasseen
veracsd@a.isi.edu
∂26-Jun-87 2250 @RELAY.CS.NET:CORK@cs.umass.edu Tracing locally defined functions
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 26 Jun 87 22:50:12 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ag10427; 27 Jun 87 1:39 EDT
Received: from cs.umass.edu by RELAY.CS.NET id bf00359; 27 Jun 87 1:33 EDT
Date: Fri, 26 Jun 87 16:18 EDT
From: "Dan Corkill A356 LGRC (413)545-0156" <CORK%cs.umass.edu@RELAY.CS.NET>
Subject: Tracing locally defined functions
To: Common-Lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-Lisp@SAIL.STANFORD.EDU",CORK
This is a plea for Common Lisp implementers to augment their TRACE utility to
handle functions defined using FLET and (especially!) LABELS. For example,
here is a recursive definition of FACTORIAL with argument checking that uses
LABELS to define a recursively invoked helper function:
(defun FACTORIAL (n)
(check-type n (integer 0 *))
(labels
((factorial-helper (n)
(cond ((zerop n) 1)
(t (* n (factorial-helper (- n 1)))))))
(factorial-helper n)))
If I wanted to trace factorial and factorial-helper, I would at least hope
that I could add the following expression to the function definition:
(defun FACTORIAL (n)
(check-type n (integer 0 *))
(labels
((factorial-helper (n)
(cond ((zerop n) 1)
(t (* n (factorial-helper (- n 1)))))))
(when (member 'factorial (trace) :TEST #'eq) ; <---
(trace 'factorial-helper)) ; <---
(factorial-helper n)))
The trace of factorial-helper is initialized within the scope of the LABELS
special form, conditionally based on the trace status of the enclosing
factorial function. Once I've completed debugging, the clause would be
removed.
I believe this ``patch'' is slightly better than avoiding LABELS until all
debugging is complete, but the technique is quite ugly.
A better solution would have implementers augment TRACE with the ability to
trace locally defined functions that are defined within a function:
(TRACE factorial :LOCALLY-DEFINED-FUNCTIONS t)
where TRACE would be smart enough to also trace any functions defined by FLET
and LABELS. Specific functions might also be an option:
(TRACE factorial :LOCALLY-DEFINED-FUNCTIONS '(factorial-helper)).
One means of implementing such an extension to TRACE would have the LABELS
and FLET special forms check at initialization time whether the functions
they are defining are to be traced. (I would be satisifed if this check was
only performed for interpreted code.) When factorial is encapsulated, the
information that factorial-helper should also be traced when it is defined
would be stored for later use by LABELS. LABELS would create the local
function and also encapsulate it for TRACE. Then the body of the LABELS
would be evaluated.
Without the ability to trace functions defined by FLET and LABELS, these
forms loose much of their attractiveness--especially to novice programmers.
I consider the definition of factorial using LABELS to be a good example
of Common Lisp programming style, but without the ability to trace its
behavior it is difficult to recommend such programming style to beginners.
Does anyone's implementation of TRACE handle LABELS or FLET?
-- Dan Corkill
∂27-Jun-87 1337 sandra%orion@cs.utah.edu print question
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 27 Jun 87 13:37:00 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA24317; Sat, 27 Jun 87 14:38:55 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA23897; Sat, 27 Jun 87 14:38:47 MDT
Date: Sat, 27 Jun 87 14:38:47 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8706272038.AA23897@orion.utah.edu>
Subject: print question
To: common-lisp@sail.stanford.edu
In the description of how to print conses on p. 368 of CLtL, the
algorithm says to "print a space" between successive list elements. Is
this supposed to be taken literally? I have been having some problems
with large data structures printing out on a single line that's too long
for other utilities (like text editors!) to handle. It is very annoying
to have your application write files you can't look at. Turning
*print-pretty* on does give me a file that the editor can read, but some
of the data structures I'm trying to print are so deeply nested that I
would really prefer not to have all that extra whitespace -- *I* can't
read what it's printing.
I know that some people will say it's the editor that's wedged, but I
think that in some cases it would be much more user-friendly to write
out a newline instead of a space when the line length exceeds 80
characters or so. In other cases (like writing to a string output
stream) I probably do not want to get a newline unless I explicitly ask
for one. Maybe the real solution is to add another parameter to write?
Or should this be an attribute of the particular output stream? I don't
have a specific proposal in mind (and I really cringe at the thought of
making CL bigger!), but I thought the problem was worth mentioning....
-Sandra
-------
∂28-Jun-87 1146 edsel!bhopal!jonl@navajo.stanford.edu print question
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jun 87 11:46:38 PDT
Received: by navajo.stanford.edu; Sun, 28 Jun 87 11:43:55 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA01509; Sun, 28 Jun 87 05:24:48 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00660; Sun, 28 Jun 87 05:27:40 PDT
Date: Sun, 28 Jun 87 05:27:40 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706281227.AA00660@bhopal.edsel.uucp>
To: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu
Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 27 Jun 87 14:38:47 MDT <8706272038.AA23897@orion.utah.edu>
Subject: print question
Although the MacLisp printer took care to insert "newline"'s ocasionally,
I finally came to believe that PRINT was the wrong place to handle this.
We ultimately made it a per-stream property -- whether or not to break
long lines -- but one thing I proposed for VAX/NIL and for Interlisp-D
(which I don't think ever got implemented) was to put the line-breaking
code into the stream. That is, some low-level byte-output method in a
stream would be paying attention so such matters of whether or not to
substitute a "newline" for an ocasional "space", in order to limit the
line length of the output [of course, you would still lose for long
sequences of characters that had no spaces at all in them]. The main
advantage of doing it "in the stream" is user-coded "printers" based
over WRITE-CHAR or WRITE-STRING would also get the benefit.
-- JonL --
∂28-Jun-87 1801 RWK@YUKON.SCRC.Symbolics.COM Tracing locally defined functions
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jun 87 18:00:58 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 231472; Sun 28-Jun-87 20:59:54 EDT
Date: Sun, 28 Jun 87 20:59 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Tracing locally defined functions
To: "Dan Corkill A356 LGRC (413)545-0156" <CORK%cs.umass.edu@RELAY.CS.NET>
cc: Common-Lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 26 Jun 87 16:18 EDT from "Dan Corkill A356 LGRC (413)545-0156" <CORK%cs.umass.edu@RELAY.CS.NET>
Message-ID: <870628205952.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Fri, 26 Jun 87 16:18 EDT
From: "Dan Corkill A356 LGRC (413)545-0156" <CORK%cs.umass.edu@RELAY.CS.NET>
A better solution would have implementers augment TRACE with the ability to
trace locally defined functions that are defined within a function:
(TRACE factorial :LOCALLY-DEFINED-FUNCTIONS t)
where TRACE would be smart enough to also trace any functions defined by FLET
and LABELS. Specific functions might also be an option:
(TRACE factorial :LOCALLY-DEFINED-FUNCTIONS '(factorial-helper)).
Does anyone's implementation of TRACE handle LABELS or FLET?
-- Dan Corkill
(trace 'foo) would have to refer to the global value. One simple
technique for tracing from inside a program would be to a
(TRACEF place).
The real problem is that Common Lisp thinks that all functions can
be named with symbols. This just isn't the case. Function names
are inherently structured objects. Our function specs allow us
to trace not just internal functions, but functions living on
property lists, in flavor method tables, in type descriptor objects,
etc. etc. In general, they are either a symbol (i.e. the trivial
CL usage), or (<type> <primary-name> . <additional info>)
For example, (flavor:method open-the-door door)
refers to the function which implements the OPEN-THE-DOOR
operation for a DOOR flavor. Another benefit is that the
user doesn't have to know where it's stored or how to get
at it.
Unfortunately, our :INTERNAL function-spec type is a little
awkward; you have to know an internal index. For anonymous
lambdas, this makes sense, and the index is zero-origin, so
it's not that hard to deal with, but you'd like to be able to
skip the index when it's unambiguous.
For example, your FACTORIAL-HELPER internal function would
be known as (:INTERNAL FACTORIAL 0 FACTORIAL-HELPER)
in our system. A better scheme would be:
(:INTERNAL FACTORIAL FACTORIAL-HELPER 0), where the 0 is optional,
so long as there's just one FACTORIAL-HELPER local function.
I think we proposed this years ago, but nobody saw the need
back then. Perhaps now there's enough experience with the
language to let us adopt something like this?
∂29-Jun-87 0707 dml@NADC.ARPA Re: MODIFYF
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jun 87 07:06:51 PDT
Received: by NADC.ARPA (5.51/1.0 )
id AA27336; Mon, 29 Jun 87 10:06:30 EDT
Date: Mon, 29 Jun 87 10:06:30 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8706291406.AA27336@NADC.ARPA>
To: VERACSD@a.isi.edu, common-lisp@sail.stanford.edu
Subject: Re: MODIFYF
Cc: veracsd@a.isi.edu
In reference to Bob Sasseen's idea of a Modifyf macro:
(Modifyf (CAR x) + 3) <-> (SETF (CAR x) (+ (CAR x) 3))
We have implemented a different, but similar macro:
(DEFMACRO Self (place function-or-form) ...)
Self can take a place and a single function to modify the place with:
(Self object CDDDR) <-> (SETF object (CDDDR object))
If function-or-form is a form, not the name of a function, then Self replaces
the symbol :self with the place:
(Self (Structure-Thing struc) (DELETE NIL :self)) <->
(SETF (Structure-Thing struc) (DELETE NIL (Structure-Thing struc)))
If place is of type (Function1 (Function2 ...)), Self takes care that
(Function2 ...) is only evaled once:
(Self (CAR (SECOND x)) 1+) <->
(LET ((#:|(second x)| (SECOND x)))
(SETF (CAR #:|(second x)|) (1+ (CAR #:|(second x)|))))
I think this is more generally useful than MODIFYF because the
modified field need not be the first argument of the modifier.
I don't feel that Self, Modifyf, or any similar modify macro
should be made part of CL until questions such as robustness vs. readability
can be resolved.
David Loewenstern
Naval Air Development Center
code 7013
Warminster, PA 18974-5000
<dml@nadc.arpa>
∂29-Jun-87 1031 Mailer@xx.lcs.mit.edu print question
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Jun 87 10:31:08 PDT
Received: from XX.LCS.MIT.EDU by navajo.stanford.edu with TCP; Mon, 29 Jun 87 10:27:47 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jun 87 13:28-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 49628; 29 Jun 87 13:30:24-EDT
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 3998; 29 Jun 87 13:00:20-EDT
Date: Mon, 29 Jun 87 12:56 EDT
From: Don Morrison <dfm@jasper.palladian.com>
Subject: print question
To: edsel!bhopal!jonl@navajo.stanford.edu
Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: <8706281227.AA00660@bhopal.edsel.uucp>
Message-Id: <870629125637.0.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@live-oak.lcs.mit.edu>
Date: Sun, 28 Jun 87 05:27:40 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Although the MacLisp printer took care to insert "newline"'s ocasionally,
I finally came to believe that PRINT was the wrong place to handle this.
I would think that it does need to be handled higher up than character I/O. I
would expect newlines to replace spaces between tokens, but not spaces embedded
within tokens, such as strings; otherwise you can't parse what you print. Or am
I missing something?
∂29-Jun-87 2210 @RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET Re: A multi-byte character extension proposal
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Jun 87 22:09:48 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02113; 30 Jun 87 0:04 EDT
Received: from utokyo-relay by RELAY.CS.NET id aj16893; 29 Jun 87 23:53 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA14909; Mon, 29 Jun 87 13:26:26 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet)
id AA04557; Mon, 29 Jun 87 13:25:54+0900
Date: Mon, 29 Jun 87 13:25:54+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8706290425.AA04557@tansei.cc.u-tokyo.junet>
To: baggins@ibm.com,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Re: A multi-byte character extension proposal
Cc: common-lisp@SAIL.STANFORD.EDU
I got a mail from nippon UNIVAC person as for the matter.
He is one of the contributors of Kanji WG.
Here is his comment.
(I am just acting as a junction between japanese net and US.)
If someone is interested in his reply, I will forward
mails to him (since direct mailing is not premitted.)
Masayuki Ida
============================ his comment =================================
Date: Fri, 26 Jun 87 16:46:31 JST
From: tshimizu@xxx.yyy.junet (Toshihiko Shimizu)
To: ida@u-tokyo.junet
Subject: Our comments to Thom Linden's q
We have reviewed the JEIDA proposal and Mr. Thom Linden's
questions. We have been making efforts for an implementation of the
extention of Common Lisp for Japanese character processing on Explorer
lisp machine. Our efforts have been made in pararell to the JEIDA
Kanji WG activity, and our specifications had been nearly fixed before
the final proposal was issued. But our implementation almost conforms
to the proposal except the point left being implementation dependent.
We think it is important to answer Linden's question according to our
implementation for your information.
First we have to give an overview of our implementation. Our primary
goal is completely the same as the JEIDA proposal that we want to use
Japanese characters "as almost the same as" characters already
available. In Explorer, an extended ASCII character set called Lisp
Machine character set has been used. We have added a new character
set for Japanese characters called JIS character set which is defined
to be the standard in Japan. This set has double-byte character code.
Explorer has the capability to handle strings whose elements are 2
byte long. This string type can be considered to be a subtype of type
string. Then we use this type of strings to hold double-byte
characters. Apparently these strings are able to hold single-byte
characters as mixture. This implementation is considered almost the
same as the scheme using "internal-thin-string" type described in the
proposal. We are now preparing a paper on this implementation for
WGSYM IPSJ, September 1987. Please refer it for further detailes.
The followings are our answers to Linden's questions;
1)
All Common Lisp standard characters are included in the standared JIS
character set, but they have different character code from the ones in
ASCII character set. This situation is almost likely in case of usual
file systems which allow JIS character set. Then we think these
difference has to be preserved when files are read into Lisp as a
sequance of characters. After that we can think of parsing, discussed
later.
2)
Above interpretation seems to lead to a contradiction against the
description in CLtL (p.233). We think that two distinct character
objects may have the same print glyphs, but in this case they shold
have the same syntactic properties. Indeed they are different
characters but somtimes we doubt. Because they may be printed using
various fonts and sometimes these printed figures are very similar.
3), 4)
Actually we have both single-byte and double-byte representations for
some characters. But we never try to map them into the one except
when the Lisp reader parses them. This is because these difference
have to be preserved as described above. And we think that once these
two representation is mapped into the one, there are no reasonable way
to make inverse mapping. This is the crucial point for applications
on Lisp to interact with other conventional applications. Suppose we
have a text processing application on Lisp and we want use it against
a text file in which single-byte and double-byte characters are
containted in mixture. It is not desirable if all single-byte
characters in the source text file are mapped into double-byte ones.
5)
Now our stand point is that a double-byte character can be a standard
character within the parsing context only if its printed glyph is
regarded as a standard character. As a result, there must be some
test for this correspondence. Acturally we have this "equivalence
test". Both the single-byte character set and the double-byte
character set include standard characters. If a character from the
single-byte character set which is a standard character, there is a
corresponding character in the double-byte character set. And these
two characters pass the "equivalence test", but they never be EQ.
However this point may lead to a contradiction to the description in
CLtL (p.20).
5a)
Then, our implementation recognizes some double-byte characters as
standard characters. For example, STANDARD-CHAR-P returns T against
#\a in the double-byte character set.
5b)
Our implementation takes option 3 in the proposal. That is, we don't
distinguish single-byte and double-byte versions of symbols, but we
preserve these difference within strings. For example, two version of
a symbol 'LAMBDA are considered to be EQ, but two versions of a string
"LAMBDA" are distinguished, or not EQUAL, but they pass the test
described above. Further, there may be mixed versions of a string
"LAMBDA".
5c)
We might agree Linden's point if we didn't think about strings.
Actually our primary understanding was that there was no need to
distinguish such a difference for the sole purpose of Common Lisp.
But there is a certain requirement for interaction with conventional
applications in which distinction between single-byte and double-byte
version is significant. Then we decided that the distinction is not
neccessary for symbols which plays an important role in programs,
whereas it is neccessary for strings which are primarily used for
interaction with outer world, such as files, displays, and networks.
5d)
As we defined that a double-byte character may be a standard
character, it is consistent to define such a character to satisfy
ALPHA-CHAR-P. Then both version of a character 'a' satisfy
ALPHA-CHAR-P, ALPHANUMERICP and LOWER-CASE-P.
5e)
We think that these description sholud be eraborated, but the JEIDA
committee has decided that these should be left implementation
dependent.
6)
In our implementation, such syntactic attributes relevant to parsing
and format controlling are only defined for standard characters. That
is, if a character is a double-byte character and also a standared
character at the same time, it may have non-constituent syntax.
Indeed it has the same syntax attribute as the single-byte version of
it. For example, a string "123" in double-byte version is also parsed
into a number 123. Otherwise its syntax cannot be other than
constituent.
7)
We think it is not neccessary to have such a large readtable which
covers all characters of type string-char. We only have a readtable
for single-byte characters and uses the "equivalent" mapping for the
double-byte version of these characters. And the rest of double-byte
characters are defined to have constituent syntax.
8)
In our implementation, MAKE-DISPATCH-MACRO-CHARACTER against a
non-standard, double-byte character is an error.
------------- end of the message -----------
∂30-Jun-87 1021 @RELAY.CS.NET:HASSETT@sp.unisys.com 2 namespaces & a complement to #' notation
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 30 Jun 87 10:21:03 PDT
Received: from relay2.cs.net by RELAY.CS.NET id af06830; 30 Jun 87 12:11 EDT
Received: from sp.unisys.com by RELAY.CS.NET id ac20556; 30 Jun 87 12:05 EDT
Date: Tue, 30 Jun 87 11:05 CDT
From: Jim Hassett <HASSETT%sp.unisys.com@RELAY.CS.NET>
To: common-lisp@SAIL.STANFORD.EDU
Subject: 2 namespaces & a complement to #' notation
X-VMS-To: IN%"common-lisp@SAIL.STANFORD.EDU"
The recent article by Kers (Christopher Dollin) concerning the two-namespace
issue and Pop gives me an excuse for bringing up a related item. I'll be
surprised if this idea has not been discussed before, but I've only been on
this list for a year, so I haven't seen it. Like Kers, I recently
read "Issues of Separation in Function Cells and Value Cells" by Gabriel &
Pitman. I have been unable to resolve my personal preferences on this
issue. I like the elegance and notational simplicity of a single
namespace, but I also find it convenient that I needn't worry much about
selecting names for lexical variables in Common Lisp. I might find a
single namespace easier to accept were it not for a mere handful of very
useful functions whose names happen to be very useful variable names (e.g.,
COUNT, LIST, STRING, and GET-SETF-METHOD-MULTIPLE-VALUE :-).
But perhaps it is too late to change Common Lisp to a single-namespace Lisp
dialect. If so, we should look for ways to mitigate the problems of having
two namespaces. One problem is the awkwardness of having to use FUNCALL to
invoke a function which is the (ordinary) value of a variable or other
form. This is illustrated by Gabriel & Pitman with definitions of the Y
operator (or paradoxical combinator) of lambda calculus. For a language
with a single namespace, the definition given is
(defun y (f)
((lambda (g) (lambda (h) ((f (g g)) h)))
(lambda (g) (lambda (h) ((f (g g)) h)))))
For a language with separate function and value namespaces, the definition
is more complex:
(defun y (f)
((lambda (g) #'(lambda (h) (funcall (funcall f (funcall g g)) h)))
#'(lambda (g) #'(lambda (h) (funcall (funcall f (funcall g g)) h)))))
(Note: My copy of the Gabriel & Pitman paper omits the second #', but it is
needed to prevent attempted evaluation of the lambda expression.)
To simplify the notation of this definition, we could alter the evaluation
of forms to allow the definition a macro character, perhaps #@, to
complement the #' syntax. A form preceded by #@ in the function position
would have its ordinary value used as the function to be applied. The
definition of Y would then be shorter, if not prettier:
(defun y (f)
((lambda (g) #'(lambda (h) (#@(#@f (#@g g)) h)))
#'(lambda (g) #'(lambda (h) (#@(#@f (#@g g)) h)))))
The effect of this change can be obtained in Common Lisp by the following
inelegant technique. Define ORDINARY-FUNCTION-VALUE-READER to convert a #@
form into a lambda-expression which applies the value of the form to its
arguments, and install this function to handle the #@ macro character:
(defun ordinary-function-value-reader (stream subchar arg)
(declare (ignore subchar arg))
`(lambda (&rest args) (apply ,(read stream t nil t) args)))
(set-dispatch-macro-character #\# #\@ #'ordinary-function-value-reader)
This works, but a better implementation would allow some new expression
such as (ordinary-value <form>) to be used in the function position,
analogous to the current use of lambda expressions.
Has this approach been considered? Is it just too ugly to get much
support? Or am I missing a serious problem?
Jim Hassett
∂01-Jul-87 0742 @Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com Flavors for KCL
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jul 87 07:42:33 PDT
Received: from MCC.COM by SU-SCORE.ARPA with TCP; Wed 1 Jul 87 07:37:25-PDT
Received: from pp.mcc.com by MCC.COM with TCP; Wed 1 Jul 87 09:28:21-CDT
Posted-Date: Wednesday, 1 July 1987, 08:32-CDT
Message-Id: <8707011334.AA29297@pp.mcc.com>
Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA70505)
id AA29297; Wed, 1 Jul 87 08:34:16 cdt
Date: Wednesday, 1 July 1987, 08:32-CDT
From: <krall%pp.mcc.com%pp.mcc.com@mcc.com>
Sender: krall%pp.mcc.com@mcc.com
Subject: Flavors for KCL
To: common-lisp@SAIL.STANFORD.EDU
Does anyone have access to a machine independent Flavors or a Flavors
for Kyoto Common Lisp. We have some software here written for Symbolics
in Common Lisp with Flavors and would like to port it to KCL will minimal
change.
-Ed Krall
Parallel Processing Program
Microelectronics and Computer Technology Corporation
3500 West Balcones Center Drive
Austin, Texas 78759
(512) 338-3406
ARPA: krall@mcc.com
UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall
∂02-Jul-87 0534 mab@mind.Princeton.EDU Loop Macro (after Zetalisp, franz, etc.)
Received: from PRINCETON.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87 05:34:18 PDT
Received: by Princeton.EDU (5.51/1.29)
id AA08478; Thu, 2 Jul 87 08:32:54 EDT
Received: by mind.Princeton.EDU (4.12/1.52)
id AA06027; Thu, 2 Jul 87 08:36:08 edt
Date: Thu, 2 Jul 87 08:36:08 edt
From: Marie Bienkowski <mab@mind.Princeton.EDU>
Message-Id: <8707021236.AA06027@mind.Princeton.EDU>
To: common-lisp@sail.stanford.edu
Subject: Loop Macro (after Zetalisp, franz, etc.)
Has anyone ported the powerful loop macro provided
with, e.g., the Symbolics Zetalisp, into regular
common lisp. I am particularly interested in a
version for Lucid Common Lisp.
Thanks,
Marie
(mab@mind.princeton.edu)
∂02-Jul-87 0812 mab@flash.bellcore.com Loop Macro (after Zetalisp, Franz, etc.)
Received: from FLASH.BELLCORE.COM by SAIL.STANFORD.EDU with TCP; 2 Jul 87 08:11:57 PDT
Received: by flash.bellcore.com (4.12/4.7)
id AA12487; Thu, 2 Jul 87 08:25:11 edt
Date: Thu, 2 Jul 87 08:25:11 edt
From: mab@flash.bellcore.com (Marie Bienkowski)
Message-Id: <8707021225.AA12487@flash.bellcore.com>
To: common-lisp@sail.stanford.edu
Subject: Loop Macro (after Zetalisp, Franz, etc.)
Has anyone ported the wonderful loop macro provided
e.g., with Symbolics Zetalisp, into regular Common
Lisp (most particularly, Lucid Common Lisp).
Even a port into another Common Lisp would be helpful.
Thanks in advance
Marie
∂02-Jul-87 0911 kempf%hplabsc@hplabs.HP.COM Location of defsys.l?
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 2 Jul 87 09:11:01 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 2 Jul 87 09:10:13 pdt
Received: by hplabsc ; Thu, 2 Jul 87 08:11:34 pdt
Date: Thu, 2 Jul 87 08:11:34 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8707021511.AA22363@hplabsc>
To: common-lisp@sail.stanford.edu
Subject: Location of defsys.l?
Some time ago, someone posted the location of a public domain defsys.l
on SAIL, which I neglected to save. Could someone who has it either
mail it or send me the location? I would be eternally grateful.
Jim Kempf kempf@hplabs.hp.com
∂02-Jul-87 1355 @RELAY.CS.NET:GREENBERG@cs.umass.edu Questions about (function eq)
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 2 Jul 87 13:55:02 PDT
Received: from relay2.cs.net by RELAY.CS.NET id au00953; 2 Jul 87 11:47 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ay00482; 2 Jul 87 1:08 EDT
Date: Wed, 1 Jul 87 14:25 EDT
From: Michael Greenberg <GREENBERG%cs.umass.edu@RELAY.CS.NET>
Subject: Questions about (function eq)
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"common-lisp@sail.stanford.edu"
I have several questions concerning the difference between
(pushnew 'foo bar :test #'eq)
and
(pushnew 'foo bar :test 'eq)
What are the semantic differences? Is there
a difference between
(defun xyz ()
(flet ((eq (a b) (bar a b)))
(pushnew 'foo bar :test #'eq)))
and
(defun xyz ()
(flet ((eq (a b) (bar a b)))
(pushnew 'foo bar :test 'eq)))
What are the stylistic differences?
Which of the following macro definitions
is preferred? Why?
(defmacro foo (fn)
(if (eq fn 'eq)
'(expansion-1 ...)
'(expansion-2 ...)))
(defmacro foo (fn)
(if (eq fn #'eq)
'(expansion-1 ...)
'(expansion-2 ...)))
(defmacro foo (fn)
(if (or (eq fn #'eq) (eq fn 'eq))
'(expansion-1 ...)
'(expansion-2 ...)))
Michael Greenberg
greenberg@cs.umass.edu
∂02-Jul-87 1510 barmar@Think.COM Questions about (function eq)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Jul 87 15:10:39 PDT
Received: from ubaldo by Think.COM via CHAOS; Thu, 2 Jul 87 18:11:50 EDT
Date: Thu, 2 Jul 87 18:09 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Questions about (function eq)
To: Michael Greenberg <GREENBERG%cs.umass.edu@relay.cs.net>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8707022101.AA29766@Think.COM>
Message-Id: <870702180943.1.BARMAR@UBALDO.THINK.COM>
Date: Wed, 1 Jul 87 14:25 EDT
From: Michael Greenberg <GREENBERG%cs.umass.edu@relay.cs.net>
What are the semantic differences? Is there
a difference between
(defun xyz ()
(flet ((eq (a b) (bar a b)))
(pushnew 'foo bar :test #'eq)))
and
(defun xyz ()
(flet ((eq (a b) (bar a b)))
(pushnew 'foo bar :test 'eq)))
Yes there is. In the first case, PUSHNEW will call your local function
EQ, while in the second case it will call the global one. The second
one is equivalent to
(defun xyz ()
(flet ((eq (a b) (bar a b)))
(pushnew 'foo bar :test (symbol-function 'eq))))
FLET creates a lexical binding, it doesn't do anything to the symbol's
function cell; therefore, if PUSHNEW is given the symbol, all it can do
is call SYMBOL-FUNCTION to extract its global function binding.
What are the stylistic differences?
Since there are semantic differences, I don't think the stylistic
differences matter. Style choices don't come into play unless you're
choosing between equivalent operations.
Which of the following macro definitions
is preferred? Why?
(defmacro foo (fn)
(if (eq fn 'eq)
'(expansion-1 ...)
'(expansion-2 ...)))
(defmacro foo (fn)
(if (eq fn #'eq)
'(expansion-1 ...)
'(expansion-2 ...)))
(defmacro foo (fn)
(if (or (eq fn #'eq) (eq fn 'eq))
'(expansion-1 ...)
'(expansion-2 ...)))
I don't think any of them are even right. You presumably meant the
conditional to be one of
(equal fn ''eq)
(equal fn '#'eq)
or
(or (equal fn '#'eq) (equal fn ''eq))
because macros are passed the data structure from the form, not the
evaluation (you have to use EQUAL because they are lists). I'm assuming
that FOO is intended to be called as
(FOO 'EQ)
or
(FOO #'EQ)
If you want to allow both forms, then my third conditional would be the
one to use.
If you want it to be callable as (FOO EQ), then your (not my) first form
would be correct.
I don't think this will do the right thing in the face of
locally-shadowed functions, though. The conditional is only looking at
the list structure, i.e. it is checking whether its argument is the list
whose first element is either the symbol FUNCTION or the symbol QUOTE
and whose second element is the symbol EQ. In the #'EQ case, the macro
has no way of evaluating this in the appropriate lexical environment in
order to check whether it refers to the "real" EQ function. If the
expansion contains ,FN or #'EQ, though, it will refer to a local EQ
function if there is one, because macro expansions get processed in the
caller's lexical scope.
For this reason, I recommend that you not try to do this as a macro. If
you do it as a function you can compare the argument against
(SYMBOL-FUNCTION 'EQ), and conditionalize it at that time. If you
really need the performance gain that the macro provides, you should
clearly document the fact that it assumes that #'EQ is the standard EQ.
In general, macros and FLET can have some weird interactions. Every
macro makes assumptions about the functional values of symbols. For
example,
(defmacro bar (a b)
`(list (cons ,a 1) (cons ,b 2)))
makes an assumption about LIST. If one then did
(defun quux (c)
(flet ((list (thing) (car thing)))
(bar c (1+ c))))
an error would be reported because the local function LIST was being
called with the wrong number of arguments, because this is equivalent to
(defun quux (c)
(flet ((list (thing) (car thing)))
(list (cons c '1) (cons (1+ c) '2))))
Macros, as they are currently defined, don't obey lexical scoping,
because they are very simple rewrite rules.
There has been some research on new ways to define macro expansion that
don't have these problems, and there is some investigation taking place
in X3J13, the ANSI Common Lisp standardization committee. For now,
though, that's the way it is.
barmar
∂02-Jul-87 1643 primerd!enx!doug@EDDIE.MIT.EDU
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87 16:43:26 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7
id <AA05553@EDDIE.MIT.EDU>; Thu, 2 Jul 87 19:41:57 EDT
Received: by primerd.prime.com (3.2/SMI-3.0DEV3/smail)
id AA12485; Thu, 2 Jul 87 13:54:14 EDT
Message-Id: <8707021754.AA12485@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 02 Jul 87 13:06:38 EST
To: COMMON-LISP@SAIL.STANFORD.EDU
From: primerd!DOUG@ENX.Prime.PDN
Date: 02 Jul 87 13:06:38 EST
To: Commonlisp (common-lisp@sail.stanford.edu)
From: Doug Rand (DOUG@ENX.PRIME.COM)
Date: 02 Jul 87 1:04 PM
Subject: Re: Location of defsys.l?
They are on defsys.lsp[com,lsp] and defsys.doc[com,lsp] on SAIL.
To add to the meager documentation (I'll eventually fix this in
defsys.doc):
:needed-systems lets a system require other systems. So to use system A
you would like systems B and C to be loaded you can specify this with
:needed-systems (B C). This means that B and C will be loaded before
A. It also means that when you compile-system A then B and C with be
recompiled (as if you typed (compile-system B) (compile-system C)
before (compile-system A)). This behavior is controlled by
the :include-components keyword arg to load-system and compile-system.
The obscure sentence about :recompile-on means that the module with
be recompiled if the date-time-modified (DTM) of any of the named,
updated modules is newer then the module's DTM. This is a common
concept in utilities like UNIX MAKE and I'm suprised that this is
a new concept for LISPer's.
Cheers,
Doug
∂02-Jul-87 1651 jeff%JASPER.Palladian.COM@XX.LCS.MIT.EDU Loop Macro (after Zetalisp, Franz, etc.)
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87 16:51:47 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 2 Jul 87 19:42-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 50147; 2 Jul 87 19:35:44-EDT
Received: from CHUGACH.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 4262; 2 Jul 87 18:37:44-EDT
Date: Thu, 2 Jul 87 18:33 EDT
From: <jeff@JASPER.Palladian.COM>
Subject: Loop Macro (after Zetalisp, Franz, etc.)
To: Marie Bienkowski <mab@flash.bellcore.com>,
common-lisp@sail.stanford.edu
In-Reply-To: <8707021225.AA12487@flash.bellcore.com>
Message-ID: <"870702183327.7.jeff@JASPER"@CHUGACH.Palladian.COM>
Reply-To: jeff%JASPER@LIVE-OAK.LCS.MIT.EDU
Date: Thu, 2 Jul 87 08:25:11 edt
From: mab@flash.bellcore.com (Marie Bienkowski)
Has anyone ported the wonderful loop macro provided
e.g., with Symbolics Zetalisp, into regular Common
Lisp (most particularly, Lucid Common Lisp).
Even a port into another Common Lisp would be helpful.
Thanks in advance
Marie
Read below. This is an exerpt from our local copy of the file which the exerpt
describes. We use this with Lucid Common Lisp. BTW, the file is about 58K bytes.
jeff
;;;; LOOP Iteration Macro
;;; This is the "officially sanctioned" version of LOOP for running in
;;; Common Lisp. It is a conversion of LOOP 829, which is fairly close to
;;; that released with Symbolics Release 6.1 (803). This conversion was
;;; made by Glenn Burke (one of the original author/maintainers); the
;;; work was performed at Palladian Software, in Cambridge MA, April 1986.
;;;
;;; The current version of this file will be maintained at MIT, available
;;; for anonymous FTP on MC.LCS.MIT.EDU from the file "LSB1;CLLOOP >". This
;;; location will no doubt change sometime in the future.
[NB. It appears to have been moved to AI.AI.MIT.EDU in "GSB;CLLOOP >" -jeff]
;;;
;;; This file, like the LOOP it is derived from, has unrestricted
;;; distribution -- anyone may take it and use it. But for the sake of
;;; consistency, bug reporting, compatibility, and users' sanity, PLEASE
;;; PLEASE PLEASE don't go overboard with fixes or changes. Remember that
;;; this version is supposed to be compatible with the Maclisp/Zetalisp/NIL
;;; LOOP; it is NOT intended to be "different" or "better" or "redesigned".
;;; Report bugs and propose fixes to BUG-LOOP@MC.LCS.MIT.EDU;
;;; announcements about LOOP will be made to the mailing list
;;; INFO-LOOP@MC.LCS.MIT.EDU. Mail concerning those lists (such as requests
;;; to be added) should be sent to the BUG-LOOP-REQUEST and
;;; INFO-LOOP-REQUEST lists respectively. Note the Change History page
;;; below...
;;;
;;; LOOP documentation is still probably available from the MIT Laboratory
;;; for Computer Science publications office:
;;; LCS Publications
;;; 545 Technology Square
;;; Cambridge, MA 02139
;;; It is Technical Memo 169, "LOOP Iteration Macro", and is very old. The
;;; most up-to-date documentation on this version of LOOP is that in the NIL
;;; Reference Manual (TR-311 from LCS Publications); while you wouldn't
;;; want to get that (it costs nearly $15) just for LOOP documentation,
;;; those with access to a NIL manual might photocopy the chapter on LOOP.
;;; That revised documentation can be reissued as a revised technical memo
;;; if there is sufficient demand.
∂06-Jul-87 0937 @Score.Stanford.EDU,@MCC.COM:krall%pp.mcc.com@mcc.com Atoms in association lists
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jul 87 09:37:34 PDT
Received: from MCC.COM by SU-SCORE.ARPA with TCP; Mon 6 Jul 87 09:32:56-PDT
Received: from pp.mcc.com by MCC.COM with TCP; Mon 6 Jul 87 11:36:45-CDT
Posted-Date: Monday, 6 July 1987, 11:34-CDT
Message-Id: <8707061637.AA02959@pp.mcc.com>
Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA70505)
id AA02959; Mon, 6 Jul 87 11:37:16 cdt
Date: Monday, 6 July 1987, 11:34-CDT
From: <krall%pp.mcc.com%pp.mcc.com@mcc.com>
Sender: krall%pp.mcc.com@mcc.com
Subject: Atoms in association lists
To: common-lisp@sail.stanford.edu
I am not sure if this is just another interpretation or (more likely) a
bug:
I write
(setq alist '((a . 1) b (c . 3)))
then try
(assoc 'c alist)
In Kyoto Common Lisp and in ZetaLisp, I get an error since the second
element of alist is not a CONS. In Golden Common Lisp, I get no
error. In fact
(assoc 'b alist) ==> nil
I like the Gold Hill implementation, however. It makes the processing of
things like
((:gettable-instance-variables a b)
:settable-instance-variables
(inittable-instance-variables c d))
easier.
Is the GCLisp interpretation wrong? If so, aside from RPLACD problems,
wouldn't the GCLisp be slightly more useful?
-Ed Krall
Parallel Processing Program
Microelectronics and Computer Technology Corporation
3500 West Balcones Center Drive
Austin, Texas 78759
(512) 338-3406
ARPA: krall@mcc.com
UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall
∂06-Jul-87 1838 OKUNO@SUMEX-AIM.STANFORD.EDU Re: Flavors for KCL
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jul 87 18:38:11 PDT
Date: Mon, 6 Jul 87 18:35:28 PDT
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Flavors for KCL
To: krall%pp.mcc.com%MCC.COM@SUMEX-AIM.STANFORD.EDU
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8707011334.AA29297@pp.mcc.com>
Organization: Knowledge Systems Laboratory
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12316328931.47.OKUNO@SUMEX-AIM.STANFORD.EDU>
Mr. Hagiya, one of the implementors of KCL ported the Flavors system
to KCL. This Flavors was originally written in Franz Lisp by Franz
Inc. Please contact him if you are interested. His E-mail address is
hagiya%kurims.kurims.kyoto-u.junet%japan.csnet@relay.cs.net
- Gitchang -
-------
∂07-Jul-87 0918 KMP@STONY-BROOK.SCRC.Symbolics.COM Atoms in association lists
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Jul 87 09:18:25 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 188793; Mon 6-Jul-87 22:34:14 EDT
Date: Mon, 6 Jul 87 22:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Atoms in association lists
To: krall%pp.mcc.com@mcc.com
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8707061637.AA02959@pp.mcc.com>
Message-ID: <870706223404.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Monday, 6 July 1987, 11:34-CDT
From: <krall%pp.mcc.com%pp.mcc.com@mcc.com>
... I write (setq alist '((a . 1) b (c . 3)))
then try (assoc 'c alist)
In Kyoto Common Lisp and in ZetaLisp, I get an error since the second
element of alist is not a CONS. In Golden Common Lisp, I get no error.
...
This is an "is an error" situation. Implementations are permitted to do
whatever they want in such a situation since you are not supposed to ever
cause this situation to occur.
I like the Gold Hill implementation, however. It makes the processing of
things like
((:gettable-instance-variables a b)
:settable-instance-variables
(inittable-instance-variables c d))
easier.
Nothing to do with your question, but I wouldn't use ASSOC for this anyway,
since using it implies to me that you're looping over possible keywords doing
ASSOC rather than looping over the supplied options checking validity. This
is bad for at least three reasons that come immediately to mind:
* You won't detect mis-spelled or totally bogus keywords. For example,
(ASSOC ':INITABLE-INSTANCE-VARIABLES your-list) will return NIL
both because you didn't write it in the keyword package and because
you didn't spell it right.
* It will seem as if :SETTABLE-INSTANCE-VARIABLES is missing because
(ASSOC ':SETTABLE-INSTANCE-VARIABLES your-list) will return NIL.
I guess you can MEMBER for it later, but that seems really odd to me.
* You won't correctly detect duplications. eg,
((:gettable-instance-variables a) (:gettable-instance-variables b))
which you may want to treat like:
((:gettable-instance-variables a b))
or at least you way want to warn about.
Getting back to your original question, though...
Is the GCLisp interpretation wrong?
I can't really speak for GCLisp. Even if it does this, you'd better check
their documentation carefully to see if it is documented behavior. If it's
not, they'd be within their rights to change the behavior incompatibly
between releases, leaving your code broken.
I know that Maclisp used to have a similar behavior, but it worked by
never doing an atom test before taking CAR of the alist entry. That
generally worked out fine because the (CAR symbol) returned something
which you couldn't make any other way and hence were not likely to be
searching for. (It wouldn't surprise me to find that
(ASSOC (CAR 'A) '(A)) => A
in compiled Maclisp.) Anyway, CL could surely not tolerate an
interpretation that allowed blind CAR'ing into symbols. CL implementations
represent symbols in lots of different ways, and some of them might have
interesting user-accessible objects in the slot that CAR would look in,
so asking ASSOC to ignore atoms would mean putting an explicit atom check
in the ASSOC inner loop, which might be very slow in some implementations.
Also, efficiency aside, there's an error-checking argument. Even if we
made atoms in an alist be legal, that wouldn't mean that every time an
atom occurred in an alist it was there intentionally. Ill-formed alists
are easy to construct. If we made it legal to have atoms at toplevel in
an alist, an interesting class of program bugs that could have been
detected would not be detectable because we could not tell whether the
atom was there by design or by accident. In fact, entry to the debugger
is not always bad. The KCL and Zetalisp versions are doing you a favor
by flagging a buggy situation in your code; GCLisp is apparently not
doing you that favor.
If so, aside from RPLACD problems, wouldn't the GCLisp be slightly
more useful?
I doubt any claimed usefulness would be worth the price in lost efficiency
and error checking. By the way, there are no RPLACD problems.
(ASSOC 'B '((A 3) B (C 4)))
returns NIL, but so does
(ASSOC 'B '((A 3) (C 4)))
You must always either do an ATOM check on the result of an ASSOC or
know absolutely for sure that the thing you're looking for is going to
be in the list before you do the RPLACD. Any RPLACD problem you're
alluding to was either already present before you brought up this issue
or was just imagined.
∂07-Jul-87 1902 OKUNO@SUMEX-AIM.STANFORD.EDU Re: Flavors for KCL
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jul 87 19:02:09 PDT
Date: Tue, 7 Jul 87 19:00:23 PDT
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Flavors for KCL
To: krall%pp.mcc.com%MCC.COM@SUMEX-AIM.STANFORD.EDU,
common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <12316328931.47.OKUNO@SUMEX-AIM.STANFORD.EDU>
Organization: Knowledge Systems Laboratory
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12316595611.63.OKUNO@SUMEX-AIM.STANFORD.EDU>
I'm sorry that I posted a wrong information on FLavors. It should read
"Mr. Hagiya, one of the implementors of KCL, ported a public domain
Flavors system to KCL. This system was originally developed at MIT".
Sorry for your inconvenience,
- Gitchang -
-------
∂08-Jul-87 0938 coffee@aerospace.aero.org Re: Atoms in association lists
Received: from [26.2.0.65] by SAIL.STANFORD.EDU with TCP; 8 Jul 87 09:38:09 PDT
Received: by aerospace.aero.org (5.54/6.0.GT)
id AA05259; Tue, 7 Jul 87 23:41:51 PDT
Posted-Date: Tue, 07 Jul 87 23:41:31 -0800
Message-Id: <8707080641.AA05259@aerospace.aero.org>
To: krall%pp.mcc.com%pp.mcc.com@mcc.com
Cc: common-lisp@sail.stanford.edu
Subject: Re: Atoms in association lists
In-Reply-To: Your message of Monday, 6 July 1987, 11:34-CDT.
<8707061637.AA02959@pp.mcc.com>
Date: Tue, 07 Jul 87 23:41:31 -0800
From: coffee@aerospace.aero.org
I wonder how Gold Hill would handle the example on p. 281 of CLtL, i.e., a
NIL appearing in place of a pair in the a-list and an invocation of
(assoc nil a-list). Steele notes that (assoc item list :test fn) is
equivalent to (find item list :test fn :key #'car) *except* in this case,
because the FIND will take the CAR of NIL and succeed with NIL while the
ASSOC "will ignore the NIL in the a-list and continue to search for an
actual pair (cons) whose CAR is NIL." I rather suspect that the Gold Hill
implementation will fail to make this distinction, and if so I would consider
this a bug (no matter how special the case may be).
∂08-Jul-87 1224 dml@NADC.ARPA Re: Atoms in association lists
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 8 Jul 87 12:23:49 PDT
Received: by NADC.ARPA (5.51/1.0 )
id AA11071; Wed, 8 Jul 87 15:00:19 EDT
Date: Wed, 8 Jul 87 15:00:19 EDT
From: dml@NADC.ARPA (D. Loewenstern)
Message-Id: <8707081900.AA11071@NADC.ARPA>
To: coffee@aerospace.aero.org, krall%pp.mcc.com%pp.mcc.com@mcc.com
Subject: Re: Atoms in association lists
Cc: common-lisp@sail.stanford.edu
Actually, GCLisp handles atoms in alists by ignoring them, whether they are
strings, NIL, or other symbols. E.g.,
(SETQ abc '(c (c . 3) NIL (NIL . 4)))
(ASSOC 'c abc) --> (c . 3)
(ASSOC nil abc) --> (NIL . 4)
This is in accordance with CLtL, I believe.
David Loewenstern
Naval Air Development Center
code 7013
Warminster, PA 18974-5000
<dml@nadc.arpa>
∂08-Jul-87 1448 Daniels.pa@Xerox.COM Re: Atoms in association lists
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Jul 87 14:48:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUL 87 14:34:02 PDT
Date: 8 Jul 87 14:33 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: Atoms in association lists
In-reply-to: dml@NADC.ARPA (D. Loewenstern)'s message of Wed, 8 Jul 87
15:00:19 EDT
To: dml@NADC.ARPA
cc: coffee@aerospace.aero.org, krall%pp.mcc.com%pp.mcc.com@mcc.com,
common-lisp@sail.stanford.edu
Message-ID: <870708-143402-2869@Xerox>
Ignoring NIL in an alist is in accordance with CLtL. Any other non-cons
in an alist is an error and may be dealt with as you see fit.
-- Andy. --
∂08-Jul-87 2038 edsel!bhopal!jonl@navajo.stanford.edu print question
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Jul 87 20:37:53 PDT
Received: by navajo.stanford.edu; Wed, 8 Jul 87 20:35:09 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA04214; Wed, 8 Jul 87 20:23:28 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03874; Wed, 8 Jul 87 20:27:01 PDT
Date: Wed, 8 Jul 87 20:27:01 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8707090327.AA03874@bhopal.edsel.uucp>
To: navajo!DFM%JASPER%LIVE-OAK.LCS.MIT.EDU@navajo.stanford.edu
Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu,
navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: Don Morrison's message of Mon, 29 Jun 87 12:56 EDT
Subject: print question
[This may have been answered already]
MacLisp "streams" had an operation which basically amounted to saying
"I want to output an n-character, unbroken sequence". By using this
rather internal operation, the PRINT function would insure that streams
with line-breaking capability didn't put the breaks at inappropriate
places. I guess this means that the PRINT function is still somewhat
involved.
-- JonL --
∂08-Jul-87 2202 edsel!bhopal!jonl@navajo.stanford.edu Loop Macro (after Zetalisp, franz, etc.)
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Jul 87 22:02:47 PDT
Received: by navajo.stanford.edu; Wed, 8 Jul 87 21:59:43 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA04307; Wed, 8 Jul 87 21:33:03 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA04024; Wed, 8 Jul 87 21:36:35 PDT
Date: Wed, 8 Jul 87 21:36:35 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8707090436.AA04024@bhopal.edsel.uucp>
To: navajo!mab%mind.Princeton.EDU@navajo.stanford.edu
Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: Marie Bienkowski's message of Thu, 2 Jul 87 08:36:08 edt
Subject: Loop Macro (after Zetalisp, franz, etc.)
A MacLisp/Zetalisp LOOP facility is ready for "beta testing" in the Lucid 2.1
image; it is not a standard part of the 2.1 release, but can be obtained as a
set of loadable files.
It may be possible to retro-fit the "beta" LOOP for the 2.0 image also.
-- JonL --
∂09-Jul-87 0358 sidney%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Atoms in association lists
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 03:58:21 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Jul 87 06:58-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 50791; 9 Jul 87 06:58:16-EDT
Date: Thu, 9 Jul 87 06:05 EDT
From: sidney%acorn@oak.lcs.mit.edu
Subject: Atoms in association lists
To: krall%pp@mcc.com
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8707061637.AA02959@pp.mcc.com>
Message-ID: <870709060531.1.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM>
The behavior of assoc in current versions of Gold Hill's GCLISP is
to not signal an error when it encounters an atom in an alist. It is not
a matter of evaluating the car of an atom as nil, thus
(assoc nil '((a 1) b (nil 5)) => (nil 5)
This behavior is a deficiency in the error checking, even if technically
not a bug. It is not an intentional interpretation of the standard.
GCLISP v3.0, our first version which fully conforms to CLtL, corrects
this.
-- sidney markowitz <sidney%acorn@oak.lcs.mit.edu>
Gold Hill Computers
∂09-Jul-87 0359 sidney%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: Atoms in association lists
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 03:59:32 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Jul 87 06:59-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 50792; 9 Jul 87 06:58:34-EDT
Date: Thu, 9 Jul 87 06:23 EDT
From: sidney%acorn@oak.lcs.mit.edu
Subject: Re: Atoms in association lists
To: dml@NADC.ARPA
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8707081900.AA11071@NADC.ARPA>
Message-ID: <870709062325.2.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM>
Actually, GCLisp handles atoms in alists by ignoring them,
whether they are strings, NIL, or other symbols. E.g.,
(SETQ abc '(c (c . 3) NIL (NIL . 4)))
(ASSOC 'c abc) --> (c . 3)
(ASSOC nil abc) --> (NIL . 4)
This is in accordance with CLtL, I believe.
David Loewenstern
--------
Since NIL is a list as well as an atom and (car NIL) => NIL
the correct result is
(assoc NIL '((c . 3) NIL (NIL . 4))) => NIL
The version of GCLisp I work with (2.4) evaluates it correctly. If an
earlier version does return (NIL . 4) then it is a bug. (I didn't try it
on any earlier versions.)
-- sidney markowitz <sidney%acorn@oak.mit.edu>
Gold Hill Computers
∂09-Jul-87 0452 @DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM Re: Atoms in association lists
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 9 Jul 87 04:52:04 PDT
Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 103750; Thu 9-Jul-87 07:50:39 EDT
Date: Thu, 9 Jul 87 07:49 EDT
From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>
Subject: Re: Atoms in association lists
To: sidney%acorn@oak.lcs.mit.edu, dml@NADC.ARPA
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870709062325.2.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM>
Message-ID: <870709074958.7.CYPHERS@RAVEN.S4CC.Symbolics.COM>
Date: Thu, 9 Jul 87 06:23 EDT
From: sidney%acorn@oak.lcs.mit.edu
Actually, GCLisp handles atoms in alists by ignoring them,
whether they are strings, NIL, or other symbols. E.g.,
(SETQ abc '(c (c . 3) NIL (NIL . 4)))
(ASSOC 'c abc) --> (c . 3)
(ASSOC nil abc) --> (NIL . 4)
This is in accordance with CLtL, I believe.
David Loewenstern
--------
Since NIL is a list
But NIL is not a cons. See page 281 of CLtL.
as well as an atom and (car NIL) => NIL
the correct result is
(assoc NIL '((c . 3) NIL (NIL . 4))) => NIL
(NIL . 4) should be returned, as someone stated earlier.
The version of GCLisp I work with (2.4) evaluates it correctly. If an
earlier version does return (NIL . 4) then it is a bug. (I didn't try it
on any earlier versions.)
-- sidney markowitz <sidney%acorn@oak.mit.edu>
Gold Hill Computers
∂09-Jul-87 0521 thoms@caen.engin.umich.edu OPS5
Received: from CAEN.ENGIN.UMICH.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 05:21:01 PDT
Received: by caen.engin.umich.edu (5.31/umix-2.0)
id AA00351; Thu, 9 Jul 87 08:04:05 EDT
Date: Thu, 9 Jul 87 08:04:05 EDT
From: thoms@caen.engin.umich.edu (Dale E Thoms)
Message-Id: <8707091204.AA00351@caen.engin.umich.edu>
To: common-lisp@sail.stanford.edu
Subject: OPS5
Does anyone know of an OPS5 interpreter written
in CommonLisp? Any information you could give me
would be much appreciated.
My net address is:
thoms@caen.engin.umich.edu
Thanks,
Dale Thoms
EECS Department
University of Michigan
∂09-Jul-87 0546 dml@NADC.ARPA Re: Atoms in association lists
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jul 87 05:45:49 PDT
Received: by NADC.ARPA (5.51/1.0 )
id AA05017; Thu, 9 Jul 87 08:45:29 EDT
Date: Thu, 9 Jul 87 08:45:29 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8707091245.AA05017@NADC.ARPA>
To: dml@NADC.ARPA, sidney%acorn@LIVE-OAK.LCS.MIT.EDU
Subject: Re: Atoms in association lists
Cc: common-lisp@sail.stanford.edu
1) Version 2.2, LM performs as I stated. I don't have 2.4. Personally,
I prefer this performance.
2) CLtL, p.281, "if NIL appears in the a-list in place of a pair ... ASSOC
will ignore the NIL in the a-list and continue to search for an actual
pair (cons) whose car is NIL."
If 2.4 returns NIL, then it is a bug.
∂09-Jul-87 0621 dml@NADC.ARPA Plists and NIL.
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jul 87 06:18:35 PDT
Received: by NADC.ARPA (5.51/1.0 )
id AA06374; Thu, 9 Jul 87 09:16:07 EDT
Date: Thu, 9 Jul 87 09:16:07 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8707091316.AA06374@NADC.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Plists and NIL.
Cc: dml@NADC.ARPA
1) NIL is a symbol. Like all symbols, it has a plist (see CLtL p.4 for an
example).
2) NIL is a list.
Therefore, does (SETQ z NIL)
(SETF (GETF z :a) :b)
z
return NIL or (:a :b)? (That is, does the property go on NIL's plist or
directly into the list referenced by z?)
Golden Common LISP (ver. 2.2LM) resolves this by having no plist on NIL. I
consider this a bug, however.
David Loewenstern
<dml@nadc>
∂09-Jul-87 0919 johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK kcl
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 9 Jul 87 09:18:45 PDT
Received: from cvaxa.sussex.ac.uk by nss.Cs.Ucl.AC.UK via Janet with NIFTP
id aa11401; 9 Jul 87 17:13 BST
From: John Williams <johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK>
Date: Thu, 9 Jul 87 16:58:14 gmt
Message-Id: <27802.8707091658@cvaxa.sussex.ac.uk>
To: common-lisp@sail.stanford.edu
Subject: kcl
Does anyone know of a UK distrubtion point for Kyoto Common Lisp ?
I have a licence that has been approved by Kyoto U; but can't FTP
the sources from the US as described in an earlier posting.
Many thanks,
john
∂09-Jul-87 0930 @RELAY.CS.NET:hagiya%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Re: Flavors for KCL
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 9 Jul 87 09:30:28 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac09037; 9 Jul 87 12:18 EDT
Received: from utokyo-relay by RELAY.CS.NET id am10711; 9 Jul 87 12:12 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA26575; Fri, 10 Jul 87 00:38:41 JST
Received: by titcca.cc.titech.junet (4.12/6.2Junet)
id AA26856; Fri, 10 Jul 87 00:11:36 jst
Received: by nttlab.NTT (4.12/6.2NTT.f) with TCP; Thu, 9 Jul 87 19:43:30 jst
Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet)
id AA14586; Thu, 9 Jul 87 12:33:01 jst
Received: by kurims.kurims.kyoto-u.junet (3.2/6.2Junet)
id AA00314; Thu, 9 Jul 87 10:15:33 JST
Date: Thu, 9 Jul 87 10:15:33 JST
From: Masami Hagiya <hagiya%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <hagiya@kurims.kurims.kyoto-u.junet>
Message-Id: <8707090115.AA00314@kurims.kurims.kyoto-u.junet>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Re: Flavors for KCL
Mr. Hagiya, one of the implementors of KCL ported the Flavors system
to KCL. This Flavors was originally written in Franz Lisp by Franz
Inc. Please contact him if you are interested. His E-mail address is
hagiya%kurims.kurims.kyoto-u.junet%japan.csnet@relay.cs.net
- Gitchang -
What I obtained from Franz (directly from the president) is the
so called Old Flavors, which is in the public domain, and which
is different from Franz's Flavors or Symbolics' New Flavors.
Gitchang's comment is not correct in that I did not port Old Flavors
to KCL, but my collegue Yuasa did. Moreover, since Old Flavors is
written in dynamically scoped Lisp, he could not completely port it
to KCL. As he is not satisfied with the result, he does not want
to give the code away.
If you are interested in obtaining the code, try to persuade him.
-- Masami Hagiya
∂09-Jul-87 1118 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK UK KCL
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 9 Jul 87 11:17:21 PDT
Received: from aiva.edinburgh.ac.uk by nss.Cs.Ucl.AC.UK via Janet with NIFTP
id aa13164; 9 Jul 87 18:53 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Thu, 9 Jul 87 18:52:11 -0100
Message-Id: <29800.8707091752@aiva.ed.ac.uk>
To: johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK
Subject: UK KCL
Cc: common-lisp@sail.stanford.edu
We have a copy at Edinburgh that we are able to redistribute under the same
conditions as U-Texas (that is, one must send in the license forms first),
but it has not yet put it in place for ftp from outside the local ethernet.
That will happen any day now, once certain admin. details have been dealt
with. Instructions for obtaining a copy will be posted in the UK at that
time.
-- Jeff
∂09-Jul-87 1207 AI.BOYER@MCC.COM Re: kcl
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 9 Jul 87 12:07:01 PDT
Date: Thu 9 Jul 87 14:03:42-CDT
From: Bob Boyer <AI.BOYER@MCC.COM>
Subject: Re: kcl
To: johnw%cvaxa.sussex.ac.uk@NSS.CS.UCL.AC.UK
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <27802.8707091658@cvaxa.sussex.ac.uk>
Message-ID: <12317044043.39.AI.BOYER@MCC.COM>
ajcole%ai.leeds.ac.uk@Cs.Ucl.AC.UK has a copy and may help
you out.
-------
∂09-Jul-87 1207 Daniels.pa@Xerox.COM Re: Plists and NIL.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jul 87 12:07:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUL 87 11:35:19 PDT
Date: 9 Jul 87 11:34 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: Plists and NIL.
In-reply-to: dml@nadc.arpa (D. Loewenstern)'s message of Thu, 9 Jul 87
09:16:07 EDT
To: dml@nadc.arpa
cc: common-lisp@sail.stanford.edu
Message-ID: <870709-113519-4138@Xerox>
You seem to be confused. GETF always operates on an immediate plist,
unlike GET, which operates on the plist of a given symbol. Thus (GETF Z
:A) always refers to the plist that is the value of the variable Z.
Whether or not NIL is a symbol or has a plist does not enter into the
picture. The correct result of
(setq z ())
(setf (getf z :a) :b)
z
is the list (:a :b).
-- Andy. --
∂09-Jul-87 1208 vax135!lcuxle!elia@ucbvax.Berkeley.EDU macrolet
Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 12:08:24 PDT
Received: by ucbvax.Berkeley.EDU (5.58/1.27)
id AA24651; Thu, 9 Jul 87 10:21:07 PDT
Received: by lcuxle.UUCP (4.6/4.2)
id AA03351; Thu, 9 Jul 87 13:04:27 EDT
Date: Thu, 9 Jul 87 13:04:27 EDT
From: vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia)
Message-Id: <8707091704.AA03351@lcuxle.UUCP>
To: common-lisp@sail.stanford.edu
Subject: macrolet
When I read the explanation for macrolet on page 114, Cltl, I had a few
problems with the 'clear' example:
(defun foo (x flag)
(macrolet ((fudge (z)
;The parameters x and flag are not accessible
;at this point; a reference to flag would be to
;the global variable of that name.
`(if flag (* ,z ,z) ,z)))
;The parameters x and flag are accessible here.
(+ x
(fudge x)
(fudge (+ x 1)))))
It seems that while this is a valid example, it does not emphasize the
point that is trying to be made. While 'fudge' is being defined foo's
flag is not accessible, but since flag is quoted inside of fudge, by
the time that the body of the macrolet is run, i.e., in (+ x ...),
flag is accessible. Therefore if I run
(setq flag t) ==> t
(foo 10 nil) ==> 31 (since flag is taken as nil).
A more illustrative example might be to change the body of fudge to:
`(if ,flag (* ,z ,z) ,z) ; Evaluate flag within macro expansion
Now, by running
(setq flag t) ==> t
(foo 10 nil) ==> 231 (since flag is taken as t).
Elia Weixelbaum
∂09-Jul-87 1404 berman@vaxa.isi.edu Validation suite
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 14:04:28 PDT
Posted-Date: Thu, 09 Jul 87 14:04:38 PDT
Message-Id: <8707092104.AA04144@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA04144; Thu, 9 Jul 87 14:04:40 PDT
To: common-lisp@sail.stanford.edu
Subject: Validation suite
Date: Thu, 09 Jul 87 14:04:38 PDT
From: Richard Berman <berman@vaxa.isi.edu>
From the recent X3 committee meeting, it was gathered that, despite having
posted several messages recently to CL-VALIDATION, it is apparent that even
some people who subscribe to that mailing list haven't received my messages
regarding the available common lisp test suite.
Perhaps that mailing list is broken??
The only people that I know for sure have recieved copies of the test suite
(which is available anonomous FTP from VENERA.ISI.EDU) are those who asked me
directly for copies, and I gave them the information on where to find it.
If you need this information, get on the CL-VALIDATION mailing list. If you
ARE on it and you haven't received my messages, let Dick Gabriel know. If you
have received my messages, please send me note to that effect.
Rather than burden everyone with the full messages, send me a note if you want
the info on the validation suite. And get on CL-VALIDATION.
RB
∂09-Jul-87 1856 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Plists and NIL.
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 18:56:42 PDT
Date: Thu, 9 Jul 1987 21:59 EDT
Message-ID: <STEVER.12317119678.BABYL@MIT-OZ>
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: dml@NADC.ARPA (D. Loewenstern)
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Plists and NIL.
In-reply-to: Msg of 9 Jul 1987 09:16-EDT from dml at nadc.arpa (D. Loewenstern)
Date: Thursday, 9 July 1987 09:16-EDT
From: dml at nadc.arpa (D. Loewenstern)
1) NIL is a symbol. Like all symbols, it has a plist (see CLtL p.4 for an
example).
2) NIL is a list.
Therefore, does (SETQ z NIL)
(SETF (GETF z :a) :b)
z
return NIL or (:a :b)? (That is, does the property go on NIL's plist or
directly into the list referenced by z?)
It goes into the list referenced by Z. Your question seems to imply
an extra level of evaluation, which doesn't occur with GETF.
LISP is wonderful. It lets you say the same thing many ways.
Here are some incantations and what they do (according to Steele
and DEC-20 Common Lisp I'm using):
These change NIL's property list:
(SETQ Z NIL)
(SETF (GET Z :A) :B)
or
(SETF (GETF (SYMBOL-PLIST 'NIL) :A) :B)
or
(SETF (GET 'NIL :A) :B)
Note: (SETF (GETF Z :A) :B) gives Z the value (:A :B)
This attempts to change NIL's value:
(SETF (GETF NIL :A) :B)
These retrieve properties from NIL's property list:
(SETQ Z NIL)
(GET Z :A)
or
(GETF (SYMBOL-PLIST 'NIL) :A)
or
(GET 'NIL :A)
Note: (GETF Z :A) returns NIL (since Z contains an empty
propert list)
- Stephen
∂10-Jul-87 0809 sandra%orion@cs.utah.edu special forms
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 10 Jul 87 08:09:27 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA26840; Fri, 10 Jul 87 09:11:41 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA05214; Fri, 10 Jul 87 09:11:37 MDT
Date: Fri, 10 Jul 87 09:11:37 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8707101511.AA05214@orion.utah.edu>
Subject: special forms
To: common-lisp@sail.stanford.edu
Is it legit to implement a CL special form as a macro that expands into
an implementation-specific special form? (For example, making FUNCTION
expand into a CLOSURE form in some circumstances.) I do not think this
would cause problems for code-walkers that use the procedure described
on p. 57, since the code-walker is expected to have its own handling
for all of the CL special forms and should never try to macroexpand
them. Assuming this is allowed, should SPECIAL-FORM-P be true of the
implementation-specific special forms or only those listed in CLtL?
-Sandra
-------
∂10-Jul-87 0942 RAM@C.CS.CMU.EDU special forms
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jul 87 09:42:03 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Fri 10 Jul 87 12:40:45-EDT
Date: Fri, 10 Jul 1987 12:40 EDT
Message-ID: <RAM.12317280147.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: special forms
In-reply-to: Msg of 10 Jul 1987 11:11-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
Well, the implementation note on 58 implies that standard macros are
allowed to expand into implementation-dependent special forms. In
combination with the premission on 57 to implement special forms as
macros, this suggests that it is legal for special forms to be
implemented as macros that expand into implementation-dependent
special forms.
I am pretty certain that special forms, both standard and
implementation dependent, should be special-form-p. It is true that
it doesn't help a code walker much to know it has tripped over a
special form it doesn't know about, but at least it can fail
gracefully instead of treating random syntax as being evaluated forms.
Having said this, I encourage you to avoid using implementation
dependent special forms. In all the cases I have come across,
expanding into a function call works just as well. You just stick in
"'" and "#'" as necessary to prevent stuff from being evaluated. The
compiler can still special-case these "funny functions" in arbitrary
ways, but they obey function syntax, and thus make life easy for
people who don't care.
Rob
∂10-Jul-87 1116 KMP@STONY-BROOK.SCRC.Symbolics.COM Appropriate use of the Common-Lisp mailing list
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jul 87 11:16:09 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 190963; Thu 9-Jul-87 21:53:46 EDT
Date: Thu, 9 Jul 87 21:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Appropriate use of the Common-Lisp mailing list
To: Common-Lisp@SAIL.STANFORD.EDU
Message-ID: <870709215332.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The mailing list Common-Lisp@SAIL.STANFORD.EDU was created as a
communication path between the Common-Lisp designers. Since its
creation, a number of `outsiders' have asked to be added and the list
has grown to enormous proportions.
While we have allowed such `auditing' of this discussion, and while such
`auditors' have occassionally contributed usefully to the discussion,
please keep in mind that every message sent to this list takes a large
amount of CPU time on dozens of machines to deliver, a large amount of
disk space to deliver and archive, and ultimately reaches hundreds of
people, most of whom are probably very busy.
I don't wish to sound elitist, but this list is of little value to me or
the other Common-Lisp designers if the quality of conversation which
crosses it is not very high. It is not intended as a free consulting
service for us to bring novices up to speed; we just don't have the time.
If you think you have something to "contribute" but you've never
implemented a lisp or you don't have many years of experience in
serious Lisp programming, please think twice or talk it over with an
expert before asking a question of this large community which could as
easily have been answered by an individual. You can save the community
much time, disk space, work, and ultimately money -- and you can save
yourself some embarrassment.
Thanks very much for your time and cooperation.
-kmp
∂10-Jul-87 1116 KMP@STONY-BROOK.SCRC.Symbolics.COM macrolet
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jul 87 11:16:41 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 190967; Thu 9-Jul-87 22:16:49 EDT
Date: Thu, 9 Jul 87 22:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: macrolet
To: vax135!lcuxle!elia@ucbvax.Berkeley.EDU
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8707091704.AA03351@lcuxle.UUCP>
Message-ID: <870709221637.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[Aside: I don't think the purpose of the Common-Lisp list is to discuss
the choice of examples in an already published book, except perhaps,
in some cases where such examples are erroneous, misleading or
contradictory. I don't think this is such a case. Personally, I think
this would have been a good issue on which to get some private help
rather than sending mail to this list.]
Date: Thu, 9 Jul 87 13:04:27 EDT
From: vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia)
When I read the explanation for macrolet on page 114, Cltl, I had a few
problems with the 'clear' example:
(defun foo (x flag)
(macrolet ((fudge (z) ... `(if flag (* ,z ,z) ,z))) ...))
...
(setq flag t) ==> t
(foo 10 nil) ==> 31 (since flag is taken as nil).
A more illustrative example might be to change the body of fudge to:
`(if ,flag (* ,z ,z) ,z) ; Evaluate flag within macro expansion
...
Your "fixed" code above fails to proclaim FLAG special. (Also, being
special CLtL suggests the variable be called *FLAG* unless you have a
compelling reason not to name it so.) Using DEFPARAMETER (or DEFVAR)
rather than SETQ to set FLAG would have accomplished this.
But more importantly, you have confused compilation time with load time.
The SETQ (or even the DEFPARAMETER initialization) will not take place
until the code is loaded, which is generally -after- the macro has
expanded (except in the special case of interactive use, such as you
probably did to test your example). You would have to have written the
SETQ, DEFVAR, or DEFPARAMETER inside (EVAL-WHEN (EVAL COMPILE) ...) to
assure that the assignment happened at the right time (ie, before the
macroexpansion).
I won't bother to address the issue that your suggested rewrite didn't
include the removal of the FLAG variable (which is now unused) and the
resulting visual confusion which might ensue from having a function bind
a variable and then not refer to it while at the same time referring to
a variable by the same name evaluated in some other context.
All this aside, however, the code you suggest is not in a style that I
think I would encourage people to use. The need to use global state is
lamentable but often necessary. The use of compile time global state is
even trickier and more to be avoided whenever possible just because of
the confusion that can result about whether the compile time and runtime
environment are the same or not. This varies a lot from dialect to
dialect and is an easy place for code portability to be impacted.
Encouraging a style which is likely to lead to trouble in portable
programming is probably not wise. The example on p114 does not
illustrate the full power of macrolet, but it does illustrate a fairly
typical example of the way in which it is intended to be used, and
that's what's important.
∂10-Jul-87 1127 KMP@STONY-BROOK.SCRC.Symbolics.COM Plists and NIL.
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jul 87 11:26:59 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191277; Fri 10-Jul-87 14:26:06 EDT
Date: Fri, 10 Jul 87 14:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Plists and NIL.
To: dml@NADC.ARPA
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8707091316.AA06374@NADC.ARPA>
Message-ID: <870710142547.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 9 Jul 87 09:16:07 EDT
From: dml@nadc.arpa (D. Loewenstern)
1) NIL is a symbol. Like all symbols, it has a plist
(see CLtL p.4 for an example).
Correct.
2) NIL is a list.
Correct.
Therefore, does (SETQ z NIL)
(SETF (GETF z :a) :b)
z
return NIL or (:a :b)?
If you're having to ask this question, you must be confusing GET and GETF.
GETF operates on the plist-format list which is returned by the place named
in its first argument position. In the case you've described where Z
contains the empty list,
(SETF (GETF z :a) :b)
is equivalent to
(SETQ z (LIST* :a :b z))
CLtL is unambiguous on that Z should contain (:A :B) after the series
of operations you're asking about.
(That is, does the property go on NIL's plist or directly into the list
referenced by z?)
Quoting from p166 in the first line of the description of GETF:
``... searches the property list store in <place> ..."
The description of generalized variables on pp93-94 is adequate to allow you
to interpret this, but just to be clear: A place is a form which if evaluated
would access a location. Something is in a place if it would be yield by
evaluating that place. the result of evaluating Z is NIL. Z is the place,
NIL is the something that is in the place Z. The thing which is searched is
the NIL. Updating a place means causing future accesses to that place, Z, to
yield an updated value. SETF does such updating. The thing which is updated
in the case of (SETF (GETF z ...) ...) is Z since Z is the thing whose contents
are searched by GETF.
Golden Common LISP (ver. 2.2LM) resolves this by having no plist on NIL.
I consider this a bug, however.
David Loewenstern <dml@nadc>
It may be that GCLISP doesn't have a plist of NIL. My guess without doing the
requisite research is that this is a bug, but you should take it up with them,
not with the whole Common-Lisp community.
In any case, the question of whether or not NIL has a plist has no
bearing on the question of what GETF does, except in the special case
which you did not mention where (GETF (SYMBOL-PLIST sym) ...) is done.
(The description of GET is quite clear on this at the top of p165 where
it actually makes this equivalence.) Even here, there is no ambiguity
because here it is clear that you search the SYMBOL-PLIST cell:
(GETF Z 'indicator) looks in the value Z. (SETF (GETF Z 'indicator) 'value)
sets the value of Z an appropriate value so that subsequent calls to
(GETF Z 'indicator) will yield the VALUE.
(GET 'Z 'indicator) or (GETF (SYMBOL-PLIST 'Z) 'indicator) looks in the
symbol-plist of the symbol Z. (SETF (GET 'Z 'indicator) 'value) or
(SETF (GETF (SYMBOL-PLIST 'Z) 'indicator) 'value) sets the symbol-plist
of the symbol Z to an appropriate value so that subsequent calls to
(GET 'Z 'indicator) or (GETF (SYMBOL-PLIST 'Z) 'indicator) will yield
VALUE.
By the way, the telltale quotes all through the second paragraph should
be the give-away that Z is being manipulated as a symbol, not a variable.
As a symbol, accesses to it as a slot are typically the standard mode of
interaction. As a variable, references to its value are typically the
standard mode of interaction.
In my opinion, it is appropriate to bring to the attention of this
community situations in which two different vendors make the claim that
there is a unique interpretation to a passage of CLtL and where those
interpretations are not in agreement. I do not believe this is such a case.
I think that all implementors are in agreement and I think you need to do
your homework better. I'm sure your Gold Hill service representative would
have been happy to provide you with this information if you'd gone to
him/her before coming to us.
∂14-Jul-87 0816 kempf%hplabsz@hplabs.HP.COM Re: Appropriate use of the Common-Lisp mailing list
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 Jul 87 08:16:37 PDT
Received: from hplms1 by hplabs.HP.COM with TCP ; Tue, 14 Jul 87 08:14:33 pdt
Received: from hplabsz.hpl.hp.com by hplms1; Tue, 14 Jul 87 08:14:10 pdt
Return-Path: <kempf@hplabsz.hpl.hp.com>
Received: by hplabsz; Tue, 14 Jul 87 08:14:52 pdt
Date: Tue, 14 Jul 87 08:14:52 pdt
From: Jim Kempf <kempf%hplabsz@hplabs.HP.COM>
Message-Id: <8707141514.AA25943@hplabsz.hpl.hp.com>
To: @SAIL.STANFORD.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp@SAIL.STANFORD.EDU
Subject: Re: Appropriate use of the Common-Lisp mailing list
While I understand the motivation behind this note, I belive a more fruitful
approach would be to provide a forum for novices to post questions, rather
than chiding them for posting their questions to the only forum they perhaps
know about. I personally believe that Common Lisp is generally useful enough
as a language that information about how to use it should not become the
property of an "elitist" club, but rather should be available to all.
Electronic bboards are one of the most effective and timely means of
dissemintating such information.
I agree, in addition, that there should be a forum for experts, where
serious design questions can be posted, particularly with regard to
enhancements and fixes needed as a result of the standardization process.
For those users who have access to UN*X notes, a more appropriate forum
for novice questions might be the notes group comp.lang.lisp. Traffic
in this group is generally light, and mostly of the nature of "Where
can I find <unbound> implementation" or "Does anyone have experience
with <unbound> implementation" rather than questions about how to
the use the language. This is in contrast to the groups on C and
other languages, where such questions form the bulk of the notes.
Therefore, perhaps a better suggestion would be to use comp.lang.lisp
for specific questions about how to use the language, and save
this group for design questions on the language itself. Those users
who don't have a UN*X notes feed will, unfortunately, have a problem,
but notes feeds are easy to get.
Additionally, as Ken pointed out in the base note, local experts (providing
they are available) are generally even more effective than bboards, and
books are approprate for getting the bigger picture.
Jim Kempf kempf@hplabs.hp.com
∂14-Jul-87 0922 skh@spice.cs.cmu.edu Apropos case sensitive?
Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jul 87 09:22:04 PDT
Date: 14 Jul 1987 12:03-EDT
From: Steve.Handerson@spice.cs.cmu.edu
To: Common-Lisp@SAIL.STANFORD.EDU
Subject: Apropos case sensitive?
Message-Id: <553277038/skh@spice.cs.cmu.edu>
Sorry if this has already been decided, but I've been using
lucid, which has a case-sensitive apropos, and think it's
*the wrong thing*.
It's easy to write a case-sensitive apropos using a case-sensitive one,
but to do the reverse you're effectively rewriting apropos.
What if some mad C hacker was writing code for you?
"Oh yeah, apropos foo."
Did he mean FOO, Foo, or foo? Or maybe (gasp) fOO?
-- STeVe
∂14-Jul-87 0929 @MCC.COM:root%bell.cad.mcc.com@mcc.com Test - Please ignore
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 14 Jul 87 09:29:52 PDT
Received: from bell by MCC.COM with TCP; Tue 14 Jul 87 11:29:10-CDT
Date: Tue, 14 Jul 87 11:28:07 CDT
From: Self-Deluded Demigod <root%bell.cad.mcc.com@mcc.com>
Posted-Date: Tue, 14 Jul 87 11:28:07 CDT
Message-Id: <8707141628.AA05857@bell>
Received: by bell (5.51/CAD)
id AA05857; Tue, 14 Jul 87 11:28:07 CDT
To: common-lisp@sail.stanford.edu
Subject: Test - Please ignore
Cc: arisco%bell.cad.mcc.com@mcc.com
This is only a test. Please excuse the intrusion.
∂14-Jul-87 1946 vrotney@venera.isi.edu Re: Apropos case sensitive?
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 Jul 87 19:46:29 PDT
Posted-Date: Tue, 14 Jul 87 19:45:12 PDT
Received: from hpai00.isi.edu by venera.isi.edu (5.54/5.51)
id AA22941; Tue, 14 Jul 87 19:46:42 PDT
Received: by hpai00 ; Tue, 14 Jul 87 19:45:27 pdt
From: vrotney@venera.isi.edu
Message-Id: <8707150245.AA03095@hpai00>
Date: Tue, 14 Jul 87 19:45:12 PDT
Subject: Re: Apropos case sensitive?
To: Common-Lisp@sail.stanford.edu
In-Reply-To: Your message of 14-Jul-87 12:03:00
X-Mailer: NMail [$Revision: 2.6 $]
re:
--------------------------------------------------------------------------------
From: Steve.Handerson@spice.cs.cmu.edu
Sorry if this has already been decided, but I've been using
lucid, which has a case-sensitive apropos, and think it's
*the wrong thing*.
--------------------------------------------------------------------------------
I think lucid is doing the right thing according to CLTL. CLTL says
"(apropos [italics]string) tries to find all available symbols
whose print name contains [italics]string as a substring."
Since we are dealing with strings, I take "substring" here to mean
case sensitive. For example (string= "FOO" "foo") => NIL. If this is
what CLTL says however (clarification please) then two points need to
made. (1.) There are other CL implementations that do a case
INSENSATIVE apropos. (2.) The traditional apropos did a case
INSENSATIVE comparison and I find this to be a generally more useful
one.
It would have been better (I think) if CLTL had specified EXACTLY that
if apropos was given a string as an argument it would do case
sensitive, and if given a symbol it would do case insensative.
Because, on an implementation that does a strictly speaking "case
sensitive apropos" then (apropos 'foo) should not print out the
function who's print name is "foo" since the print name of the symbol
'foo is "FOO".
-------
∂15-Jul-87 2313 @RELAY.CS.NET:HELLER@cs.umass.edu RE: Apropos case sensitive?
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 15 Jul 87 23:12:53 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa23577; 16 Jul 87 2:07 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ad02188; 16 Jul 87 1:57 EDT
Date: Wed, 15 Jul 87 08:51 EDT
From: Stride 440 User <HELLER%cs.umass.edu@RELAY.CS.NET>
Subject: RE: Apropos case sensitive?
To: Common-LISP@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-LISP@sail.stanford.edu"
I too think Lucid's case-sensitive apropos is wrong. After all, APROPOS is
searching SYMBOL print-names for substring matches. In Common LISP, symbol
print-names get converted to uppercase (unless enclosed with vertical bars
or backslashed or "manually" created with intern). Thus (unless you make
heavy use either vertical bars or backslashes), most of the print-names of
the symbols typed in (or loaded from files) by users will have all uppercase
names. Since most people using Common LISP are probably not using caps only
terminals (such as the Teletype Model 33) or have the Caps-Lock key down,
they will be entering expressions (either in files or interactively) using
mostly lowercase letters. While it is posible to allways pass a SYMBOL to
apropos, this has the side affect of actually creating a symbol which will
match the symbol(s) sought (the one passed as the argument to apropos). This
is probably tolerable (although posibly confusing to novices) for
interactive queries. It can cause problems with functions using apropos-list
(functions which do something to all symbols which have some special
character sequence in them).
The apropos function on both of the other Common LISPs I have used (DEC
VAX/VMS VAX-LISP and TI Explorer LISP) is case-insensitive. In fact when I
had need to mess with Lucid LISP on a loaner SUN, I put the case-insensitive
version of apropos into the function slot of apropos in my init file (and
later into the saved system).
Also, there is in Common LISP a case-insensitve string compare function:
EQUALP. (EQUALP "FOO" "foo") => T (last example, page 82 of CLtL).
Robert Heller
ARPANet: Heller@CS.UMass.EDU
BITNET: Heller@UMass.BITNET
BIX: Heller
GEnie: RHeller
FidoNet: 321/148 (Locks Hill BBS, Wendell, MA)
CompuServe 71450,3432
Local PV VAXen: COINS::HELLER
UCC Cyber/DG: Heller@CS
∂16-Jul-87 0624 kanya@caen.engin.umich.edu Prolog
Received: from CAEN.ENGIN.UMICH.EDU by SAIL.STANFORD.EDU with TCP; 16 Jul 87 06:24:49 PDT
Received: by caen.engin.umich.edu (5.31/umix-2.0)
id AA01050; Thu, 16 Jul 87 09:09:39 EDT
Date: Thu, 16 Jul 87 09:09:39 EDT
From: kanya@caen.engin.umich.edu (Kanya Likanasudh)
Message-Id: <8707161309.AA01050@caen.engin.umich.edu>
To: common-LISP@sail.stanford.edu
Subject: Prolog
Does anyone know of a Prolog interpreter written in Common Lisp?
Any information about it would be appreciated.
My network address is:
kanya@caen.engin.umich.edu
Thank you.
-Kanya
∂16-Jul-87 1123 DALY@IBM.COM pathnames, portability, ed, eval-when, compile-file, fasl files
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 16 Jul 87 11:23:20 PDT
Date: 16 July 1987, 10:12:53 EDT
From: Timothy Daly <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <071687.101253.daly@ibm.com>
Subject: pathnames, portability, ed, eval-when, compile-file, fasl files
First question:
Is there any *portable* way to get the pathname of the file
that is currently being compiled or loaded? I would like to
be able to edit the file when an error occurs (similar to
turbo pascal).
That is, if someone types:
(compile-file ">daly>foo.lisp")
and my parser detects an error, I'd like to
(ed ">daly>foo.lisp")
but there doesn't appear to be a get-current-pathname function
defined anywhere.
Does common lisp plan to add such a function when the 'debugging
facilities' get expanded?
Actually, I'd like to be able to incant
(progn (ed ">daly>foo.lisp") (ed-search arbitrary-text-string))
which would leave the user in the editor and positioned at the error.
It appears that this could be defined in a portable manner
as every editor has a text search command.
And, dreaming on, I'd like a definition of
(ed-command arbitrary-but-implementation-dependent-editor-command)
that is, I'd like the interface syntax to the editor command handler
to be defined in a portable manner. I understand that the actual
commands to perform the manipulations would be different across
systems but I could create editor scripts and assign them to
implementation dependent variables.
Second question:
Is there any *portable* way I can tell whether a macro is being
expanded in the compile time environment or the top level
command environment?
That is, I need to set up certain compile time information for
macros. These macros perform two functions. They generate
forms for the compiler to compile into the file and they
set up top level environment information. If they are expanded
from compile-file in the compile-time environment, they modify
the global state. If they are expanded at the top level they
create and return forms that modify the global state redundantly.
Truly tedious programming gets around this problem but one of two
possible modifications to common lisp would solve *my* problem.
First, export the state used by EVAL-WHEN so I can use it (eval-when
does not seem to be available except at the top level, thus I have
to hack a compiler:phase-1-hook property which is beyond my cutoff
point for hacking this week). If I could get at the state I could
conditionalize my code without using eval-when special forms.
The second modification would be to allow me to write into a fasl
file without using compile-file. That is,
(compile 'foo :output-file pathname :if-exists :append)
If I could write compiled objects I could create my own fasl file
definition and write something portable that would get around the
previous hacks.
tim.
DALY@IBM.COM
T. J. Watson Research Center
If I had ham, I could have ham and eggs, if I had eggs. Sigh.
∂16-Jul-87 1609 RAM@C.CS.CMU.EDU editor issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jul 87 16:09:04 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 16 Jul 87 19:07:58-EDT
Date: Thu, 16 Jul 1987 19:07 EDT
Message-ID: <RAM.12318923506.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Timothy Daly <DALY@IBM.COM>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: editor issues
In-reply-to: Msg of 16 Jul 1987 10:12:53 EDT from Timothy Daly <DALY at ibm.com>
Date: 16 July 1987, 10:12:53 EDT
From: Timothy Daly <DALY at ibm.com>
Re: pathnames, portability, ed, eval-when, compile-file, fasl files
Is there any *portable* way to get the pathname of the file
that is currently being compiled or loaded?
No.
I would like to be able to edit the file when an error occurs
(similar to turbo pascal).
That is, if someone types:
(compile-file ">daly>foo.lisp")
and my parser detects an error, I'd like to
(ed ">daly>foo.lisp")
I think you are trying to do too much that is properly part of the
"programming environment", and inherently not portable (at least with
the current Common Lisp design goals).
A more portable alternative would be to have a SYNTAX-ERROR condition
and an EDIT proceed function, or something like that. This would
provide a portable interface to "editing errors", if that capability
exists.
[...] but there doesn't appear to be a get-current-pathname function
defined anywhere. Does common lisp plan to add such a function
when the 'debugging facilities' get expanded?
Well, this was mentioned before, but I believe it was by you. Unless
someone comes up with a formal proposal that convincingly argues that
this is well-defined and useful, then it won't be adopted. Although
you may think the semantics are obvious, it may be difficult to
clearly define. Consider that code may be consed up and compiled
without ever having been in a file, and that code can be read from
places other than files.
Actually, I'd like to be able to incant
(progn (ed ">daly>foo.lisp") (ed-search arbitrary-text-string))
I think that anything of this sort is doomed in the absence of a
standard editor/environment. As a practical matter this isn't very
important either. Given that the editor exists and provides the
functionality you want (which Common Lisp doesn't guarantee), you can
have a trivial (but non-portable) code file that implements what you
expect in terms of what is available.
And, dreaming on, I'd like a definition of
(ed-command arbitrary-but-implementation-dependent-editor-command)
that is, I'd like the interface syntax to the editor command
handler to be defined in a portable manner. [...] I could create
editor scripts and assign them to implementation dependent
variables.
This is just silly. Your code isn't any more portable just because
the first symbol in each form is the same. Since Lisp supports
arbitrary functional values, you can stick "editor scripts" in
variables just as easily as arbitrary code.
Rob
∂16-Jul-87 1630 RAM@C.CS.CMU.EDU eval-when issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jul 87 16:29:59 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 16 Jul 87 19:28:53-EDT
Date: Thu, 16 Jul 1987 19:28 EDT
Message-ID: <RAM.12318927315.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Timothy Daly <DALY@IBM.COM>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: eval-when issues
In-reply-to: Msg of 16 Jul 1987 10:12:53 EDT from Timothy Daly <DALY at ibm.com>
Date: 16 July 1987, 10:12:53 EDT
From: Timothy Daly <DALY at ibm.com>
Re: pathnames, portability, ed, eval-when, compile-file, fasl files
[...]
Second question:
Is there any *portable* way I can tell whether a macro is being
expanded in the compile time environment or the top level
command environment?
Probably the answer is no. A macro can do different things in these
circumstances using EVAL-WHEN, of course. Moving on out over thin
ice, I would argue that a program that needs this information is
broken, is in error, is not Common Lisp. The problem is that concepts
such as "at compile time" are very hard to pin down given the wide
range of legal Common Lisp implementation strategies such as "compile
only", "interpret only", and all kinds of hybrid/incremental
compilation schemes.
That is, I need to set up certain compile time information for
macros. These macros perform two functions. They generate
forms for the compiler to compile into the file and they
set up top level environment information. If they are expanded
from compile-file in the compile-time environment, they modify
the global state. If they are expanded at the top level they
create and return forms that modify the global state redundantly.
Truly tedious programming gets around this problem but one of two
possible modifications to common lisp would solve *my* problem.
It's hard to tell what you are trying to do, but sounds like you are
writing your macros wrong. Macroexpansion should never have
side-effects. You should get your "compile time" side-effects by
using EVAL-WHEN. If you put the stuff in an EVAL-WHEN (COMPILE LOAD EVAL),
then it will happen both at compile and load time, but only once when
interpreted at top-level.
First, export the state used by EVAL-WHEN so I can use it (eval-when
does not seem to be available except at the top level, thus I have
to hack a compiler:phase-1-hook property which is beyond my cutoff
point for hacking this week).
EVAL-WHEN (or equivalent) should work anywhere. The concept of
"top-level form" doesn't belong in Common Lisp. This is currently an
area of major lossage in the spec. I have a compiler cleanup proposal
that replaces eval-when and banishes top-level forms. This proposal
is supposedly being considered by the compiler cleanup committee.
The second modification would be to allow me to write into a fasl
file without using compile-file. That is,
(compile 'foo :output-file pathname :if-exists :append)
Gag my with a spoon! Hunh-uh... No way! fat chance, over my bloated
corpse.
Rob
∂17-Jul-87 1026 edsel!bhopal!jonl@labrea.stanford.edu Appropriate use of the Common-Lisp mailing list
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Jul 87 10:25:56 PDT
Received: by labrea.stanford.edu; Fri, 17 Jul 87 10:23:15 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA03837; Thu, 16 Jul 87 18:32:33 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA07740; Thu, 16 Jul 87 18:36:30 PDT
Date: Thu, 16 Jul 87 18:36:30 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707170136.AA07740@bhopal.edsel.uucp>
To: labrea!kempf.hplabsz%hplabs.HP.COM@labrea.stanford.edu,
labrea!KMP%SCRC.Symbolics.COM@labrea.stanford.edu
Cc: labrea!Common-Lisp%SAIL@labrea.stanford.edu
In-Reply-To: Jim Kempf's message of Tue, 14 Jul 87 08:14:52 pdt <8707141514.AA25943@hplabsz.hpl.hp.com>
Subject: Appropriate use of the Common-Lisp mailing list
[Apologies again for replying several days late -- Lucid's link, at Stanford,
to the Internet seems to have been wedged since last Friday.]
Many other forums have seen fit to divide into two mailing lists -- one for
imlementational questions and another for general "information". A paradigm
might be the BUG-<mumble> and INFO-<mumble> lists that sprang up around
MIT years ago (but maybe they weren't so successful? I dunno).
On the other hand, I don't find the (unnanounced and informal) change in
purpose of the Common-Lisp@SU-AI mailing list to be so bad; my reasons
for tolerating it are:
(1) It generates *** substantially less volume ** in my mail file than
it did one year ago, when every apostle from the MIT-AI lab (myself
included) who imagined he was designing the world's greatest language
felt it necessary to publicly argue every little issue that came up.
(2) Users, who are not implementors, frequently have a different point
of view as to what the important issues are, and they often read
standardized documentation in a way different from "wizards"; I want
to remain informed as to what they are thinking.
-- JonL --
∂20-Jul-87 1132 Kahn.pa@Xerox.COM Re: Prolog
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Jul 87 11:32:10 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 87 11:30:55 PDT
Date: Mon, 20 Jul 87 11:30:41 PDT
From: Ken Kahn <Kahn.pa@Xerox.COM>
Subject: Re: Prolog
In-Reply-To: <8707161309.AA01050@caen.engin.umich.edu>
To: kanya@caen.engin.umich.edu (Kanya Likanasudh)
cc: common-LISP@sail.stanford.edu
Message-ID: <870720-113055-1588@Xerox>
I've written one called CommonLog. Unfortunately Xerox hasn't decided
yet what to do with it. Do you know about ZYX Prolog for HP? What
other responses did you get to your message?
References
kanya@caen.engin.umich.edu's message of Thu, 16 Jul 87 9:09:39 EDT --
Prolog
∂20-Jul-87 2130 edsel!bhopal!jonl@labrea.stanford.edu Apropos case sensitive?
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:30:39 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:25:54 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA05223; Fri, 17 Jul 87 11:45:06 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00220; Fri, 17 Jul 87 11:49:11 PDT
Date: Fri, 17 Jul 87 11:49:11 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171849.AA00220@bhopal.edsel.uucp>
To: labrea!vrotney%venera.isi.edu@labrea.stanford.edu
Cc: labrea!Common-Lisp%sail@labrea.stanford.edu,
labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: vrotney@venera.isi.edu's message of Tue, 14 Jul 87 19:45:12 PDT <8707150245.AA03095@hpai00>
Subject: Apropos case sensitive?
[Note: LUCIDites are now using another mail gateway: typical address is:
edsel!jonl@labrea.stanford.edu]
Our reasoning here at Lucid was similar to what you came up with -- namely
that the language of CLtL, p. 443, very strongly implied the same semantics
of macthing as the default for SEARCH, which is an EQL, rather than an
EQUALP, test.
Many of us also felt the need so strongly for a case-insensitive apropos
that Lucid Common Lisp actually has two such functions hidden inside it:
lucid::case-insensitive-apropos
lucid::case-insensitive-apropos-list
but they will probably be "shaken" out in the delivered 2.1 beta images.
I feel that this issue should be presented to the "cleanup" sub-committee
of the X3J13 standards committee. Perhaps SEF can prod Steve Handerson
into writing up a proposal to them? Lucid might feel impelled to "expose"
this hidden function if the committe were inclined towards the proposal.
By the way, there are some other issues about apropos that might need
"cleaning up", some of which were discussed on this list a couple of
years ago (for "couple" mabye equal to one). For example, the
documentation uses the term "available symbols", but in at least one
instance, it ought to use "accessible symbols", for conformity to
chapter 11 on packages. Also, the scope of do-all-symbols has been
questioned by some; there have been at least two proposals on it:
(1) to add a new "function" called, say do-most-symbols, that excluded
certain packages
(2) to add a global variable (or a special variable) called, say,
*all-symbols-exclusions* which is a list of packages which the
several "all-symbols" functions would skip [e.g., do-all-symbols,
find-all-symbols, apropos, case-insensitive-apropos, etc]
-- JonL --
∂22-Jul-87 0715 EJS%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Re: Atoms in association lists
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jul 87 07:14:57 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 Jul 87 09:48-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 52437; 22 Jul 87 10:00:27-EDT
Date: Wed, 22 Jul 87 08:59 EDT
From: EJS%acorn@oak.lcs.mit.edu
Subject: Re: Atoms in association lists
To: Cyphers@YUKON.SCRC.Symbolics.COM, sidney%acorn@oak.lcs.mit.edu,
dml@NADC.ARPA
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870709074958.7.CYPHERS@RAVEN.S4CC.Symbolics.COM>
Message-ID: <870722085942.3.EJS@ACORN.Gold-Hill.DialNet.Symbolics.COM>
Return-path: <@OAK.Gold-Hill.DialNet.Symbolics.COM,@LIVE-OAK.LCS.MIT.EDU.ARPA,@SAIL.STANFORD.EDU.ARPA,@SAIL.STANFORD.EDU,@DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM>
Received: from LIVE-OAK.LCS.MIT.EDU.ARPA (MIT-LIVE-OAK.DialNet.Symbolics.COM) by GOLD-HILL-ACORN.DialNet.Symbolics.COM via DIAL with SMTP id 74916; 9 Jul 87 09:06:26-EDT
Received: from SAIL.STANFORD.EDU (SAIL.STANFORD.EDU.ARPA) by LIVE-OAK.LCS.MIT.EDU.ARPA via INTERNET with SMTP id 50799; 9 Jul 87 08:06:44-EDT
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 9 Jul 87 04:52:04 PDT
Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 103750; Thu 9-Jul-87 07:50:39 EDT
Date: Thu, 9 Jul 87 07:49 EDT
From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>
Subject: Re: Atoms in association lists
To: sidney%acorn@oak.lcs.mit.edu, dml@NADC.ARPA
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870709062325.2.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM>
Message-ID: <870709074958.7.CYPHERS@RAVEN.S4CC.Symbolics.COM>
Date: Thu, 9 Jul 87 06:23 EDT
From: sidney%acorn@oak.lcs.mit.edu
Actually, GCLisp handles atoms in alists by ignoring them,
whether they are strings, NIL, or other symbols. E.g.,
(SETQ abc '(c (c . 3) NIL (NIL . 4)))
(ASSOC 'c abc) --> (c . 3)
(ASSOC nil abc) --> (NIL . 4)
This is in accordance with CLtL, I believe.
David Loewenstern
--------
Since NIL is a list
But NIL is not a cons. See page 281 of CLtL.
as well as an atom and (car NIL) => NIL
the correct result is
(assoc NIL '((c . 3) NIL (NIL . 4))) => NIL
(NIL . 4) should be returned, as someone stated earlier.
The version of GCLisp I work with (2.4) evaluates it correctly. If an
earlier version does return (NIL . 4) then it is a bug. (I didn't try it
on any earlier versions.)
-- sidney markowitz <sidney%acorn@oak.mit.edu>
Gold Hill Computers
No Sidney, I believe we are not in conformance with the spec since we fail
the specific test case mentioned in CLtL. This is a long-reported bug for
which the bug form sits on my desk this very instance. It is still a bug
in 2.9.3 (beta release of 3.0).
∂23-Jul-87 1222 VERACSD@A.ISI.EDU Toplevel lexical variables
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 12:22:50 PDT
Date: 23 Jul 1987 15:19-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Toplevel lexical variables
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: veracsd.rs@A.ISI.EDU
Message-ID: <[A.ISI.EDU]23-Jul-87 15:19:07.VERACSD>
(let ((x 1))
(defun f ()
x))
According to CLtL, it seems the above should work essentially
the same at top level as it would within a function definition with
(function (lambda ... )) in place of (defun ... ).
The documentation for let (p. 111) says "each binding will be a
lexical binding unless there is a special declaration to the contrary
... The bindings of the variables have lexical scope and indefinite
extent".
The documentation for defun (p. 67) says "Evaluating a
defun form causes the symbol ... to be a global name for the function
specified by the lambda-expression ... defined in the lexical environment
in which the defun form was executed".
However, neither Symbolics nor TI seems to allow this (I may not
have checked the very latest releases).
Why would anyone want to use this? Well, because it's there, because
it's (to my taste) cleaner and more elegant than using a global special
variable, and because it's good software engineering practice not to
have things accessible from where they're not intended to be accessed.
For a practical example, one might perhaps think of a login function using
a (computed) list of passwords.
The compile function (p. 438) presumably ought to work the same way
(at least with the second argument supplied), although there isn't any
specific textual justification. Symbolics and TI don't support this
either.
Finally, if I may add a comment not about Common Lisp per se,
both Symbolics and TI fail to actually compile a defun within
a let, but make it a named-lambda instead (in addition to not scoping
it properly), when using c-sh-C from the editor, and probably do
the same when compiling and loading a file. This is tolerated by
Common Lisp (defun is one of the top-level forms of which CLtL says
on p. 66 "Compilers, for example, may not recognize these forms properly
in other than top-level contexts"), but I would think that sophisticated
implementations should do the reasonable thing here.
Bob Sasseen
∂23-Jul-87 1509 pierson@multimax.ARPA Toplevel lexical variables
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 87 15:09:11 PDT
Received: by multimax.ARPA (4.12/25-eef)
id AA06883; Thu, 23 Jul 87 18:04:23 edt
Date: Thu, 23 Jul 87 18:04:23 edt
From: Dan Pierson <pierson@multimax.ARPA>
Message-Id: <8707232204.AA06883@multimax.ARPA>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Toplevel lexical variables
If you expand the example to:
(let ((x 1))
(defun f ()
x)
(defun g (bar)
...
(setq x ...)
...))
It becomes clear that this sort of structure is quite useful. X may
be a private constant or a private "global" shared by the two top
level functions F and G. The same sort of information hiding can be
done with packages, but both the cost and code complexity will rise.
This style is more common in Scheme than Common Lisp but it seems to
me that Common Lisp implementations are required to support it.
dan
In real life: Dan Pierson, Encore Computer Corporation, Research
Usenet: {talcott,linus,necis,decvax,ihnp4}!encore!pierson
Arpanet: pierson@multimax.arpa
∂23-Jul-87 1739 VERACSD@A.ISI.EDU Correction
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 17:38:57 PDT
Date: 23 Jul 1987 20:38-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Correction
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: veracsd.rs@A.ISI.EDU
Message-ID: <[A.ISI.EDU]23-Jul-87 20:38:49.VERACSD>
I have to apologize to Symbolics. Their release 7.1 (possibly also
7.0, but not 6.1) does allow toplevel lexical variables such as described
in my posting earlier today. The user is asked whether this is really
what he wants.
I am informed that TI's upcoming release 3.0 will support this too.
(What I said about the functions not being actually compiled remains
true for 7.1; I'm not sure about 3.0.)
(I might add that Symbolics does not allow lexical bindings around
defmethods (not sure about TI); I hope they will consider it.)
A little thought has also revealed to me that there is no way one
can expect the compile function, called at runtime, to pick up lexical
bindings. The other alternative, putting the let around the second
argument to compile (as part of it) is clearly not supported by CLtL,
although it would be nice if it were.
Sorry for any inconvenience.
Bob Sasseen
∂24-Jul-87 0806 SWM@SAPSUCKER.SCRC.Symbolics.COM Correction
Received: from [128.81.41.223] by SAIL.STANFORD.EDU with TCP; 24 Jul 87 08:05:53 PDT
Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 148310; Fri 24-Jul-87 10:45:29 EDT
Date: Fri, 24 Jul 87 10:45 EDT
From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
Subject: Correction
To: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU
cc: veracsd.rs@A.ISI.EDU
In-Reply-To: <[A.ISI.EDU]23-Jul-87 20:38:49.VERACSD>
Message-ID: <870724104512.0.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM>
Date: 23 Jul 1987 20:38-EDT
From: VERACSD@A.ISI.EDU
I have to apologize to Symbolics. Their release 7.1 (possibly also
7.0, but not 6.1) does allow toplevel lexical variables such as described
in my posting earlier today. The user is asked whether this is really
what he wants.
I am informed that TI's upcoming release 3.0 will support this too.
(What I said about the functions not being actually compiled remains
true for 7.1; I'm not sure about 3.0.)
So far, they remain uncompiled.
(I might add that Symbolics does not allow lexical bindings around
defmethods (not sure about TI); I hope they will consider it.)
Isn't this what instance variables are for? In CLOS, methods get to
choose what "slots" (CLOSpeak for "instance variable") they are allowed
to access, so can get the "own variable" behavior you want that way.
A little thought has also revealed to me that there is no way one
can expect the compile function, called at runtime, to pick up lexical
bindings. The other alternative, putting the let around the second
argument to compile (as part of it) is clearly not supported by CLtL,
although it would be nice if it were.
Sorry for any inconvenience.
Bob Sasseen
∂24-Jul-87 0939 Gregor.pa@Xerox.COM Re: Correction
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Jul 87 09:39:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUL 87 09:39:17 PDT
Date: 24 Jul 87 09:38 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Correction
In-reply-to: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>'s message of
Fri, 24 Jul 87 10:45 EDT
To: SWM@SAPSUCKER.SCRC.Symbolics.COM
cc: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU,
veracsd.rs@A.ISI.EDU
Message-ID: <870724-093917-2611@Xerox>
From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
Subject: Correction
Date: 23 Jul 1987 20:38-EDT
From: VERACSD@A.ISI.EDU
(I might add that Symbolics does not allow lexical
bindings around defmethods (not sure about TI); I hope they
will consider it.)
Isn't this what instance variables are for? In CLOS, methods
get to choose what "slots" (CLOSpeak for "instance variable") they
are allowed to access, so can get the "own variable" behavior you
want that way.
No, this kind of use of lexical variables is not at all the same as
slots (instance variables). Slots are a piece of storage which is
associated with an object (in the case of class variables it can be more
than one object). Effectively that means that with respect to the body
of the method slots are dynamic variables. Needless to say, lexical
variables around a defmethod aren't dynamic variables. Here is what I
think of as a prototypical example of methods using both a slot and a
lexical variable.
(defclass plist-mixin ()
((plist :initform ()
:accessor plist)))
(let ((mark (list "mark")))
(defmethod mark ((x plist-mixin))
(setf (getf (plist x) mark) t))
(defmethod markp ((x plist-mixin))
(getf (plist x) mark))
)
∂24-Jul-87 1020 SWM@SAPSUCKER.SCRC.Symbolics.COM Re: Correction
Received: from [128.81.41.223] by SAIL.STANFORD.EDU with TCP; 24 Jul 87 10:20:26 PDT
Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 148385; Fri 24-Jul-87 13:21:07 EDT
Date: Fri, 24 Jul 87 13:20 EDT
From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
Subject: Re: Correction
To: Gregor.pa@Xerox.COM, SWM@SAPSUCKER.SCRC.Symbolics.COM
cc: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU, veracsd.rs@A.ISI.EDU
In-Reply-To: <870724-093917-2611@Xerox>
Message-ID: <870724132056.7.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM>
Date: 24 Jul 87 09:38 PDT
From: Gregor.pa@Xerox.COM
From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
Subject: Correction
Date: 23 Jul 1987 20:38-EDT
From: VERACSD@A.ISI.EDU
(I might add that Symbolics does not allow lexical
bindings around defmethods (not sure about TI); I hope they
will consider it.)
Isn't this what instance variables are for? In CLOS, methods
get to choose what "slots" (CLOSpeak for "instance variable") they
are allowed to access, so can get the "own variable" behavior you
want that way.
No, this kind of use of lexical variables is not at all the same as
slots (instance variables). Slots are a piece of storage which is
associated with an object (in the case of class variables it can be more
than one object). Effectively that means that with respect to the body
of the method slots are dynamic variables. Needless to say, lexical
variables around a defmethod aren't dynamic variables. Here is what I
think of as a prototypical example of methods using both a slot and a
lexical variable.
Thanks for unconfusing me.
(defclass plist-mixin ()
((plist :initform ()
:accessor plist)))
(let ((mark (list "mark")))
(defmethod mark ((x plist-mixin))
(setf (getf (plist x) mark) t))
(defmethod markp ((x plist-mixin))
(getf (plist x) mark))
)
∂24-Jul-87 1043 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Correction
Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 24 Jul 87 10:43:48 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 103619; Fri 24-Jul-87 13:34:38 EDT
Date: Fri, 24 Jul 87 13:33 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Correction
To: Gregor.pa@Xerox.COM, SWM@SAPSUCKER.SCRC.Symbolics.COM
cc: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU, veracsd.rs@A.ISI.EDU
In-Reply-To: <870724-093917-2611@Xerox>
Message-ID: <870724133345.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No
It seems to me that the use of lexical bindings around several methods
is rather akin to the concept of "class variables". (Except that you
control the scope by lexical containment in the let, rather than having
the scope always me the set of all methods of a class.)
∂24-Jul-87 1218 barmar@think.com Re: Correction
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 24 Jul 87 12:18:03 PDT
Received: from nietzsche by Think.COM via CHAOS; Fri, 24 Jul 87 15:12:05 EDT
Date: Fri, 24 Jul 87 15:12 EDT
From: Barry Margolin <barmar@think.com>
Subject: Re: Correction
To: Daniel L. Weinreb <DLW@alderaan.scrc.symbolics.com>
Cc: Gregor.pa@xerox.com, SWM@sapsucker.scrc.symbolics.com, VERACSD@a.isi.edu,
common-lisp@sail.stanford.edu, veracsd.rs@a.isi.edu
In-Reply-To: <870724133345.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <870724151251.2.BARMAR@NIETZSCHE.THINK.COM>
Date: Fri, 24 Jul 87 13:33 EDT
From: Daniel L. Weinreb <DLW@alderaan.scrc.symbolics.com>
It seems to me that the use of lexical bindings around several methods
is rather akin to the concept of "class variables". (Except that you
control the scope by lexical containment in the let, rather than having
the scope always me the set of all methods of a class.)
To continue further from what Dan was saying, I believe that the
response to this type of thing in the past has been to suggest that the
class should be broken up into two classes. In Gregor's example, the
LET would be replaced by a MARK-MIXIN, which would have the class
variable MARK.
barmar
∂25-Jul-87 2249 @RELAY.CS.NET:MURRAY@cs.umass.edu EOF-VALUE
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jul 87 22:49:22 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac21038; 26 Jul 87 1:49 EDT
Received: from cs.umass.edu by RELAY.CS.NET id bt15822; 26 Jul 87 1:39 EDT
Date: Sat, 25 Jul 87 19:53 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
Subject: EOF-VALUE
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: CLMAIL
What is the default value of EOF-VALUE for all the read functions?
For example, READ takes (&Optional input-stream eof-error-p eof-value).
If only INPUT-STREAM and EOF-ERROR-P are supplied, and EOF-ERROR-P is non-nil,
CLtL says that the value of EOF-VALUE will be returned if an end-of-file
is found. Without any further specification, I must assume that it
defaults to NIL, which is the default default value for unsupplied &Optionals.
For READ-CHAR, and READ-BYTE, NIL is an impossible value, but for READ
and company, NIL is a perfectly reasonable return value.
Thus, it makes no sense to supply a non-nil second argument, but not the third.
In fact, the only safe value for EOF-VALUE in these cases is some
non-atomic object that could never be EQ to something read in.
For this reason, In just about every file that calls read, I've got something
like (Defconst *eof-value* (cons nil nil)), (maybe it's eof-value, or
si:eof-value, or sys:**eof-value**, I can never remember), so I can supply
and test for it as an EOF-VALUE.
I would like to suggest the addition of new constant, *eof-value*, that
is the default value for EOF-VALUE in all the read functions.
Every system using something like this, why not make it standard?
- Kelly Murray
∂26-Jul-87 1433 smh@EMS.MEDIA.MIT.EDU Re: EOF-VALUE
Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 87 14:33:21 PDT
Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA17837; Sun, 26 Jul 87 17:24:57 EDT
Date: Sun, 26 Jul 87 17:24:57 EDT
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
Message-Id: <8707262124.AA17837@EMS.MEDIA.MIT.EDU>
To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU
Subject: Re: EOF-VALUE
From: MURRAY%cs.umass.edu@RELAY.CS.NET
I would like to suggest the addition of new constant, *eof-value*, that
is the default value for EOF-VALUE in all the read functions.
This is not *quite* an upward compatible change. An existing
application using READ could reasonably depend on NIL being synonymous
to a real EOF. Although the proposed change is otherwise cogent, I
would opt against it since the benefit is only minor convenience and
not increased functionality.
∂26-Jul-87 1623 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU EOF-VALUE
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 87 16:23:36 PDT
Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 50335; Sun 26-Jul-87 19:23:37 EDT
Date: Sun, 26 Jul 87 19:23 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: EOF-VALUE
To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 25 Jul 87 19:53 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET
Message-ID: <870726192338.4.CFRY@JONES.AI.MIT.EDU>
What is the default value of EOF-VALUE for all the read functions?
For example, READ takes (&Optional input-stream eof-error-p eof-value).
If only INPUT-STREAM and EOF-ERROR-P are supplied, and EOF-ERROR-P is non-nil,
CLtL says that the value of EOF-VALUE will be returned if an end-of-file
is found. Without any further specification, I must assume that it
defaults to NIL, which is the default default value for unsupplied &Optionals.
For READ-CHAR, and READ-BYTE, NIL is an impossible value, but for READ
and company, NIL is a perfectly reasonable return value.
Thus, it makes no sense to supply a non-nil second argument, but not the third.
In fact, the only safe value for EOF-VALUE in these cases is some
non-atomic object that could never be EQ to something read in.
For this reason, In just about every file that calls read, I've got something
like (Defconst *eof-value* (cons nil nil)), (maybe it's eof-value, or
si:eof-value, or sys:**eof-value**, I can never remember), so I can supply
and test for it as an EOF-VALUE.
I would like to suggest the addition of new constant, *eof-value*, that
is the default value for EOF-VALUE in all the read functions.
Every system using something like this, why not make it standard?
- Kelly Murray
I second this proposal. Make EOF processing easy!
∂27-Jul-87 0949 barmar@think.com EOF-VALUE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 87 09:49:03 PDT
Received: from nietzsche by Think.COM via CHAOS; Mon, 27 Jul 87 11:51:35 EDT
Date: Mon, 27 Jul 87 11:29 EDT
From: Barry Margolin <barmar@think.com>
Subject: EOF-VALUE
To: MURRAY%cs.umass.edu@relay.cs.net
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8707260551.AA27872@Think.COM>
Message-Id: <870727112913.6.BARMAR@NIETZSCHE.THINK.COM>
Date: Sat, 25 Jul 87 19:53 EDT
From: MURRAY%cs.umass.edu@relay.cs.net
[...]
For this reason, In just about every file that calls read, I've got something
like (Defconst *eof-value* (cons nil nil)), (maybe it's eof-value, or
si:eof-value, or sys:**eof-value**, I can never remember), so I can supply
and test for it as an EOF-VALUE.
I would like to suggest the addition of new constant, *eof-value*, that
is the default value for EOF-VALUE in all the read functions.
Every system using something like this, why not make it standard?
While I admit that it is common, it is not foolproof, because someone
can type #.*eof-value*. The only really safe eof value is an object
consed on the fly, as in
(let ((eof-value (ncons '*eof-value*))) ;self-documenting structure
...
(read *standard-input* nil eof-value)
...)
The only way one could get at that value is by using a debugger or some
other internal hack to look in the lexical environment, and they don't
count.
However, I wouldn't object strongly to adding *eof-value*, as anyone who
types #.*eof-value* deserves what they get.
barmar
∂27-Jul-87 1423 gls@Think.COM EOF-VALUE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 87 14:23:07 PDT
Received: from polycarp by Think.COM via CHAOS; Mon, 27 Jul 87 15:33:27 EDT
Date: Mon, 27 Jul 87 15:26 EDT
From: Guy Steele <gls@Think.COM>
Subject: EOF-VALUE
To: barmar@think.com, MURRAY%cs.umass.edu@relay.cs.net
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <870727112913.6.BARMAR@NIETZSCHE.THINK.COM>
Message-Id: <870727152620.7.GLS@POLYCARP.THINK.COM>
Date: Mon, 27 Jul 87 11:29 EDT
From: Barry Margolin <barmar@think.com>
Date: Sat, 25 Jul 87 19:53 EDT
From: MURRAY%cs.umass.edu@relay.cs.net
...
...
However, I wouldn't object strongly to adding *eof-value*, as anyone who
types #.*eof-value* deserves what they get.
That's true even if we don't spec or implement it.
--Guy
∂27-Jul-87 1447 SCHMIDT@SUMEX-AIM.STANFORD.EDU Re: Toplevel lexical variables
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 87 14:46:56 PDT
Date: Mon, 27 Jul 87 14:46:58 PDT
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.STANFORD.EDU>
Subject: Re: Toplevel lexical variables
To: VERACSD%A.ISI.EDU@SUMEX-AIM.STANFORD.EDU
cc: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12321792358.60.SCHMIDT@SUMEX-AIM.STANFORD.EDU>
(DEFUN A () (DEFUN B ()
(LET ((X 1)) (LET ((X 1))
(DEFUN F () X) (SETF (SYMBOL-FUNCTION 'F)
#'(LAMBDA () X))
(DEFUN G (Y) (SETQ X Y)))) (SETF (SYMBOL-FUNCTION 'G)
#'(LAMBDA (Y) (SETQ X Y)))))
I think definition B above would provide the behavior you desire and
skirt the issue of compiling DEFUN as other than a top-level form;
hence I believe it to be more portable.
--Christopher
P.S. My apologies to the list if this is so obvious that it doesn't
bear stating.
-------
∂27-Jul-87 1706 pierson@multimax.ARPA Toplevel lexical variables
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jul 87 17:06:19 PDT
Received: by multimax.ARPA (4.12/25-eef)
id AA02229; Mon, 27 Jul 87 20:00:55 edt
Date: Mon, 27 Jul 87 20:00:55 edt
From: Dan Pierson <pierson@multimax.ARPA>
Message-Id: <8707280000.AA02229@multimax.ARPA>
To: SCHMIDT@SUMEX-AIM.STANFORD.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Toplevel lexical variables
Ah, but the original desire (as I understand it) was to have the LET
be top-level rather than nested inside of a DEFUN. CLtL allows
top-level forms to be nested inside PROGN but not LET. The use of
top-level LETs is a common, and useful, Scheme idiom. I suspect that
it was discovered by the Scheme folks first because they've had
lexical scoping longer, but we really should support it in Common
Lisp.
Your definition B followed by:
(eval-when (load eval) (b))
does the same job at the costs of: an extra function defintion and
call, and considerably more opaque syntax. I don't believe that it's
any easier to compile properly (i.e. ensure that the internal lambdas
are optionally compiled).
dan
∂28-Jul-87 0050 wade@wombat.stanford.edu EOF value
Received: from WOMBAT by SAIL.STANFORD.EDU with TCP; 28 Jul 87 00:49:55 PDT
Date: 28 Jul 87 00:48:00 PST
From: "Wade Hennessey" <wade@wombat.stanford.edu>
Subject: EOF value
To: "common-lisp" <common-lisp@sail.stanford.edu>
Reply-To: "Wade Hennessey" <wade@wombat.stanford.edu>
The stream you are reading from is usually a perfectly good EOF
value. Rod Brooks showed me this, and I have yet to encounter a
situation where it did not suffice.
Wade
------
∂29-Jul-87 0039 @RELAY.CS.NET:MURRAY@cs.umass.edu *eof-value*
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Jul 87 00:39:21 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa22549; 29 Jul 87 3:37 EDT
Received: from cs.umass.edu by RELAY.CS.NET id bj03680; 29 Jul 87 3:29 EDT
Date: Tue, 28 Jul 87 14:35 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
Subject: *eof-value*
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: CLMAIL
From: MURRAY%cs.umass.edu@RELAY.CS.NET
I would like to suggest the addition of new constant, *eof-value*, that
is the default value for EOF-VALUE in all the read functions.
>From: IN%"Steven Haflich <smh@ems.media.mit.edu>" 28-JUL-1987 01:59
>Although the proposed change is otherwise cogent, I
>would opt against it since the benefit is only minor convenience and
>not increased functionality.
But at no real cost, since the constant is going to exist anyway.
>From: Barry Margolin <barmar@THINK.COM>
>While I admit that it is common, it is not foolproof, because someone
>can type #.*eof-value*. The only really safe eof value is an object
>consed on the fly, as in..
I hadn't considered this, but it just occured to me you found a neat
way of commenting out the rest of a file!
(Assuming the loader is checking for *eof-value*, and not NIL, or something
consed on the fly, or si:*eof-value*, or etc.)
(defun foo ..)
#.*eof-value*
(defun unused-foo ..)
..
- Kelly Murray
University of Massachusetts
∂29-Jul-87 0648 smh@EMS.MEDIA.MIT.EDU Re: *eof-value*
Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 87 06:48:03 PDT
Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA08459; Wed, 29 Jul 87 09:39:29 EDT
Date: Wed, 29 Jul 87 09:39:29 EDT
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
Message-Id: <8707291339.AA08459@EMS.MEDIA.MIT.EDU>
To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU
Subject: Re: *eof-value*
From: MURRAY%cs.umass.edu@RELAY.CS.NET
I would like to suggest the addition of new constant, *eof-value*, that
is the default value for EOF-VALUE in all the read functions.
>From: IN%"Steven Haflich <smh@ems.media.mit.edu>" 28-JUL-1987 01:59
>Although the proposed change is otherwise cogent, I
>would opt against it since the benefit is only minor convenience and
>not increased functionality.
But at no real cost, since the constant is going to exist anyway.
Perhaps I wasn't really clear. The important cost is that changing
the current default value of eof-value from NIL to anything else may
break existing code that depends on (READ stream NIL) returning NIL on
eof. Even though CL might be a better language if the spec were
changed in this regard, this rather minor improvement wouldn't justify
making an incompatible change, particularly since the desired
functionality can be achieved via (READ stream NIL *EOF-VALUE*).
By the way, exporting a new symbol such as *EOF-VALUE* from the LISP
package is an incompatible change, although often a more-easily
detectible one. The problem is that code written under the old spec
will suddenly find it's like-named internal symbol(s) "unified" with
the symbol in the LISP package. If it were really a CONSTANT (why?)
than presumably any user attempt to set or even DEFVAR it will signal
an error. But even innocently adding a new exported function name can
break code that happens to use that name either as a function or a
special variable.
It will certainly happen that X3J13 will propose add new functions and
variables that must be exported from the LISP package. However, they
will weigh the cost of each such change and only make changes for
which there is a significant benefit that cannot otherwise easily be
obtained using the existing language definition.
∂31-Jul-87 1455 wile@vaxa.isi.edu Test Suite availability
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 87 14:55:48 PDT
Posted-Date: Fri, 31 Jul 87 14:33:58 PDT
Message-Id: <8707312134.AA13154@vaxa.isi.edu>
Received: from loopback by vaxa.isi.edu (5.54/5.51)
id AA13154; Fri, 31 Jul 87 14:34:02 PDT
To: COMMON-LISP@sail.stanford.edu
From: wile@vaxa.isi.edu
Subject: Test Suite availability
Date: Fri, 31 Jul 87 14:33:58 PDT
Sender: wile@vaxa.isi.edu
A Common Lisp Validation Suite has been assembled here at ISI by Richard
Berman. He essentially developed a test driver and has converted
portions of the suites of some of the vendors to his format. The suite
contains only a small fraction of the tests he has received, but it is a
start for anyone responsible for quality assurance of CL
implementations.
Unfortunately for us, Richard resigned recently (to go off and become a
recording star and/or AI in music guru), so there will be little
additional support or development until a replacement for him is found.
Although several of you are aware of the existence of this suite, we
have been told that many interested parties were not; hence, this
message. To access the suite, ftp to venera.isi.edu logging in as
anonymous. Please respond with your name and affiliation as the
password. The two directories of interest are: /usr/ftp/Valid-Code/*.*
and /usr/ftp/Valid-Tests/*.*. (Capitalization is necessary.) The file
README.NOW contains the information necessary to understand how to
invoke the test suite and what files to transfer to your machine.
Apparently around 400 tests are available now.
We have no way to monitor the activity on the files, except with the ftp
log of your anonymous password. We would very much appreciate hearing
about any successes, problems, or suggestions (perhaps as to which
remaining tests to convert first) you have. Send mail to
WILE@VAXA.ISI.EDU for now. There is a mailing list for the validation
group--named CL-VALIDATION. You get onto it by mailing to
RPG@SAIL.STANFORD.EDU.
∂31-Jul-87 2159 sandra%orion@cs.utah.edu compile-time processing of REQUIRE
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 87 21:59:39 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA09047; Fri, 31 Jul 87 23:02:09 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA05593; Fri, 31 Jul 87 23:02:05 MDT
Date: Fri, 31 Jul 87 23:02:05 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8708010502.AA05593@orion.utah.edu>
Subject: compile-time processing of REQUIRE
To: common-lisp@sail.stanford.edu
Am I correct that REQUIRE forms appearing at top level are not supposed
to be evaluated at compile time? It is not in the list of magic
functions on p. 182 of CLtL. However, both VaxLisp and Lucid attempt to
process them at compile time. Has there been a proposal to make REQUIRE
magical, that I haven't heard about?
The reason why this behavior is causing a problem for me is that I have
a number of modules which involve several files. I've found it
convenient to put all of the external interface stuff (EXPORTs, etc.) in
a separate file and have it REQUIRE the remaining files. When I compile
this top-level file, sometimes these other files don't exist yet: I
haven't compiled them yet, or I haven't copied the files to the place
where REQUIRE wants to look for them, or whatever. If this is not the
way REQUIRE was intended to be used, can somebody tell me how it *is*
supposed to be used?
-Sandra
-------
∂01-Aug-87 1031 smh@EMS.MEDIA.MIT.EDU Re: compile-time processing of REQUIRE
Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Aug 87 10:31:16 PDT
Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA25229; Sat, 1 Aug 87 13:23:25 EDT
Date: Sat, 1 Aug 87 13:23:25 EDT
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
Message-Id: <8708011723.AA25229@EMS.MEDIA.MIT.EDU>
To: common-lisp@sail.stanford.edu, sandra%orion@cs.utah.edu
Subject: Re: compile-time processing of REQUIRE
The problem is only partly one of underspecification. Depending
whether the required file contains only macros, both macros and
execution-time functions, or just execution-time functions, typically
you will want REQUIRE to happen at compile/eval, compile/load/eval, or
load/eval times.
Regardless when a naked REQUIRE does or doesn't happen, you can get
explicit control by surrounding it with an EVAL-WHEN. This will
protect somewhat from differences between implementations.
∂02-Aug-87 0808 edsel!bhopal!jonl@labrea.stanford.edu compile-time processing of REQUIRE
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Aug 87 08:08:10 PDT
Received: by labrea.stanford.edu; Sat, 1 Aug 87 22:32:50 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA07051; Sat, 1 Aug 87 22:34:04 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA08106; Sat, 1 Aug 87 22:31:24 PDT
Date: Sat, 1 Aug 87 22:31:24 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708020531.AA08106@bhopal.edsel.uucp>
To: labrea!sandra%orion%cs.utah.edu@labrea.stanford.edu
Cc: labrea!common-lisp%sail@labrea.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 31 Jul 87 23:02:05 MDT <8708010502.AA05593@orion.utah.edu>
Subject: compile-time processing of REQUIRE
re: Am I correct that REQUIRE forms appearing at top level are not supposed
to be evaluated at compile time? It is not in the list of magic
functions on p. 182 of CLtL. However, both VaxLisp and Lucid . . .
I have been under the impression that the compilation interface is one
area where CLtL, as a specification, didn't succeed very well. Although
no complete guarantee can be given to insure package layout consistency,
it seems to me that the usage pattern of REQUIRE (but *not* PROVIDE) is
such that it should be implicitly recognized by the compiler interface.
For example, see Table 11-1 of CLtL, p189:
;;;; Lisp init file for I. Newton
;;; Set upthe USER pacakge the wayk I like it.
(require 'calculus) ;I use CALCULUS a lot. Load it.
(use-package 'calculus) ;Get easy access to its exported symbols
. . .
;;; Import only what I need into the USER package.
(require 'relativity)
(import '(relativity:speed-of-light)...)
Quite evidently, the CALCULUS package is created and set up by the
calculus module; and parameters with names like RELATIVITY:SPEED-OF-LIGHT
are defined in the RELATIVITY module (indeed, isn't this the intention of
"modular" programming!). Thus this example, as a file, would not be
compilable unless the REQUIRE statements are executed, in the order in
which they appear, during the file compilation.
In addition to REQUIRE, Lucid has added UNINTERN to the set of forms
implicitly wrapped in an eval-when(eval compile load). Note that there
is nothing stopping the programmer from using his own wrappers, which
will have precedence over the implicit one.
Incidentally, one other area where I personally violate the CLtL
suggestions on package usage is in the placement of PROVIDE statements.
Section 11.9 suggests placeing them first in a file, and the cutsy little
mnemonic on page 191 -- PutInSevenExtremelyRandomUserInterfaceCommands --
also does that. But because loading a lisp file is a dynamic action
with ocasionally loooooong duration, and because it is very easy to
abort the loading right in the middle -- either interactively or through
the error system -- then I place my PROVIDE's last, so that the *MODULES*
list will not actually be updated until the whole module is fully present.
One final point: I've used the word "statements" to refer to these
functions. I hope you don't think that I'm just some kind of nerd who
learned Lisp yesterday and doesn't know enough to refer to these sorts
of things as "forms" or "s-expressions" or whatever. In fact the
functionality provided by these "...ExtremelyRandomUserInterface..."
commands is very much like that of a JobControlLanguage. That is why
I refer to them as "statements".
Allow me, if you will, to express one more very strong opinion: I
definitely prefer to write my "statements" in Lisp syntax rather than
in YAJCL*, or FORTRAN, or even the Emacs-inspired "File Attribute"
syntax of the MIT Lisp machine descendents. [Lisp is "good enough";
it does the job.]
-- JonL --
* = YetAnotherJobControlLanguage
∂03-Aug-87 0907 barmar@Think.COM New special form suggestion: LET-CONSTANT
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87 09:07:12 PDT
Received: from nietzsche by Think.COM via CHAOS; Mon, 3 Aug 87 12:06:50 EDT
Date: Mon, 3 Aug 87 12:07 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: New special form suggestion: LET-CONSTANT
To: common-lisp@sail.stanford.edu
Message-Id: <870803120736.7.BARMAR@NIETZSCHE.THINK.COM>
Today I noticed myself creating DEFCONSTANTS for symbolic constants that
would only be used by the one function I was writing. It struck me that
they really wanted to be local to the function, not top-level variables,
but I wanted to make sure that the compiler would open-code them, and I
also wanted to declare their constantness to readers. There is
currently no way to do this in Common Lisp (nor, as far as I know, in
Symbolics Common Lisp, which I was using) without DEFCONSTANT, which
also creates a useless special variable.
It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list
keyword, would be the right thing for this. LET-CONSTANT would be to
DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to
&AUX.
Actually, for consistency with the names FLET and MACROLET, I suppose
this should be called CONSTANTLET (although to me that seems like the
word for a little constant). However, I never liked those names anyway.
barmar@think.com
∂03-Aug-87 0930 samalone@ATHENA.MIT.EDU Re: New special form suggestion: LET-CONSTANT
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 09:30:24 PDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA22194; Mon, 3 Aug 87 12:28:47 EDT
From: <samalone@ATHENA.MIT.EDU>
Received: by HADES.MIT.EDU (5.45/4.7) id AA00890; Mon, 3 Aug 87 12:28:40 EDT
Message-Id: <8708031628.AA00890@HADES.MIT.EDU>
To: common-lisp@sail.stanford.edu
Subject: Re: New special form suggestion: LET-CONSTANT
In-Reply-To: Your message of Mon, 03 Aug 87 12:07:00 -0400.
<870803120736.7.BARMAR@NIETZSCHE.THINK.COM>
Date: Mon, 03 Aug 87 12:28:38 EDT
It seems like a LET-CONSTANT special form, or an &CONSTANT
lambda-list keyword, would be the right thing for this.
LET-CONSTANT would be to DEFPARAMETER what FLET is to DEFUN,
and &CONSTANT would be analogous to &AUX.
As an alternative, I recommend a CONSTANT declaration. DEFCONSTANT could then
be defined in terms of (PROCLAIM '(CONSTANT variable)). The statement
(PROCLAIM '(DECLARATION CONSTANT)) would provide compatibility with
implementations that don't support the declaration.
--Stuart A. Malone
∂03-Aug-87 1021 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM New special form suggestion: LET-CONSTANT
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 3 Aug 87 10:20:51 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110034; Mon 3-Aug-87 13:17:49 EDT
Date: Mon, 3 Aug 87 13:17 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: New special form suggestion: LET-CONSTANT
To: Barry Margolin <barmar@Think.COM>, samalone@ATHENA.MIT.EDU
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870803120736.7.BARMAR@NIETZSCHE.THINK.COM>,
<8708031628.AA00890@HADES.MIT.EDU>
Message-ID: <870803131722.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Yes, CONSTANTLET would be a better name.
Proclamations don't solve Barry's concern: he doesn't want a "useless"
variable which proclomations would require. As far as I can tell,
PROCLAIM/DEFPARAMETER is just another syntax for DEFCONSTANT and doesn't
solve anything.
On the other hand, a (DECLARE (CONSTANT XYZ)) in the declarations part
of a LET body (or of a DEFUN for &AUX) might be the way to go.
You can get what you want today, kludgily, by using MACROLET and making
the desired constants look like function calls.
I'm glad some people prefer to err on the side of naming seldom-used
constants than to wire in magic numbers into their code; numbers by
themselves don't convey much information to the casual reader.
∂03-Aug-87 1023 snyder%hplsny@hplabs.HP.COM Re: compile-time processing of REQUIRE
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87 10:21:12 PDT
Received: from hplms2 by hplabs.HP.COM with TCP ; Mon, 3 Aug 87 10:19:13 pdt
Received: from hplsny (hplsny) by hplms2; Mon, 3 Aug 87 10:18:53 pdt
Return-Path: <snyder@hplsny>
Received: from hplsny.hpl.hp.com by hplsny ; Mon, 3 Aug 87 10:18:35 pdt
Message-Id: <8708031718.AA03272@hplsny>
To: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Cc: common-lisp@sail.stanford.edu
Subject: Re: compile-time processing of REQUIRE
Reply-To: snyder@hplabs
In-Reply-To: Your message of Sat, 01 Aug 87 22:31:24 -0700.
<8708020531.AA08106@bhopal.edsel.uucp>
Date: Mon, 03 Aug 87 10:18:31 PDT
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
In addition to REQUIRE, Lucid has added UNINTERN to the set of forms
implicitly wrapped in an eval-when(eval compile load). Note that there
is nothing stopping the programmer from using his own wrappers, which
will have precedence over the implicit one.
I believe that the CLtL specification of EVAL-WHEN is inadequate to
guarantee that the programmer can achieve this effect. In particular,
following the "precise model" (p 70):
(eval-when (load eval)
(eval-when (compile load eval)
(foo)))
is no different than
(eval-when (compile load eval)
(foo))
There is no way to have a "negative" effect (such as "do NOT do this at
compile time"). I hope the "clean up" committee is addressing this issue.
Alan
∂03-Aug-87 1041 RpK%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Question on function type spec and lambda-list keywords
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 10:40:53 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 3 Aug 87 13:40-EDT
Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 54193; 3 Aug 87 13:35:58-EDT
Date: Mon, 3 Aug 87 12:39 EDT
From: RpK%acorn@oak.lcs.mit.edu
Subject: Question on function type spec and lambda-list keywords
To: common-lisp@sail.stanford.edu
Message-ID: <870803123923.1.RPK@ACORN.Gold-Hill.DialNet.Symbolics.COM>
Is the ftype of +
(function (&rest number) number)
or
(function (&rest list) number)
?
I would assume the former (since &rest args are always of type list), but
there aren't any examples in CLtL that make this clear.
∂03-Aug-87 1211 edsel!kent-state!eb@labrea.stanford.edu New special form suggestion: LET-CONSTANT
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 12:11:45 PDT
Received: by labrea.stanford.edu; Mon, 3 Aug 87 12:00:16 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA10784; Mon, 3 Aug 87 12:08:32 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
id AA11862; Mon, 3 Aug 87 12:05:52 PDT
Date: Mon, 3 Aug 87 12:05:52 PDT
From: edsel!kent-state!eb@labrea.stanford.edu (Eric Benson)
Message-Id: <8708031905.AA11862@kent-state.edsel.uucp>
To: labrea!barmar%Think.COM@labrea.stanford.edu
Cc: labrea!common-lisp%sail.stanford.edu@labrea.stanford.edu
In-Reply-To: Barry Margolin's message of Mon, 3 Aug 87 12:07 EDT <870803120736.7.BARMAR@NIETZSCHE.THINK.COM>
Subject: New special form suggestion: LET-CONSTANT
There's actually no need for a declaration or special form. LET will
do fine all by itself. If the expression to which the variable is
bound is constant and there are no SETQs to the variable, all
references to the variable may be legitimately replaced by the
constant expression. This is a very common optimization in Lisp
compilers. However, as far as I know it is not done by the Symbolics
compiler.
∂03-Aug-87 1315 vanroggen%aitg.decnet@hudson.dec.com LET-CONSTANT and DECLARE (CONSTANT
Received: from HUDSON.DEC.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87 13:15:20 PDT
Date: 3 Aug 87 16:09:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: LET-CONSTANT and DECLARE (CONSTANT
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Perhaps the complaint about "binding constants" isn't about the
constancy of association between a variable and its value, but about
whether the value happens to be read-only.
This would permit additional compiler optimizations regarding state
dependent functions like ELT.
Related question: are quoted constants in compiled functions "read-only"?
How about initial values for DEFCONSTANTs?
Is this what was intended by DECLARE (CONSTANT V)?
---Walter
------
∂03-Aug-87 1317 Moon@SAPSUCKER.SCRC.Symbolics.COM New special form suggestion: LET-CONSTANT
Received: from [128.81.41.223] by SAIL.STANFORD.EDU with TCP; 3 Aug 87 13:17:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 150921; Mon 3-Aug-87 16:18:16 EDT
Date: Mon, 3 Aug 87 16:18 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New special form suggestion: LET-CONSTANT
To: Eric Benson <edsel!kent-state!eb@labrea.stanford.edu>
cc: barmar@Think.COM, common-lisp@sail.stanford.edu
In-Reply-To: <8708031905.AA11862@kent-state.edsel.uucp>
Message-ID: <870803161813.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 3 Aug 87 12:05:52 PDT
From: edsel!kent-state!eb@labrea.stanford.edu (Eric Benson)
There's actually no need for a declaration or special form. LET will
do fine all by itself. If the expression to which the variable is
bound is constant and there are no SETQs to the variable, all
references to the variable may be legitimately replaced by the
constant expression. This is a very common optimization in Lisp
compilers. However, as far as I know it is not done by the Symbolics
compiler.
It isn't an optimization in the Symbolics 3600, for most constants. The
same is true in any other machine that keeps variables in registers and
doesn't have an immediate addressing mode capable of accomodating all Lisp
constants, I believe.
I'm not disagreeing that it is useful for compilers to make this optimization
in the cases where it is in fact an optimization. I think your reasoning for
why Common Lisp has DEFCONSTANT but no corresponding local form is correct:
the local form isn't needed since the compiler has access to everything in
the scope of a local variable and hence can infer the same information.
∂03-Aug-87 1340 RAM@C.CS.CMU.EDU LET-CONSTANT and DECLARE (CONSTANT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 13:39:57 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 3 Aug 87 16:39:50-EDT
Date: Mon, 3 Aug 1987 16:39 EDT
Message-ID: <RAM.12323615129.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: common-lisp@SAIL.STANFORD.EDU
Subject: LET-CONSTANT and DECLARE (CONSTANT
Date: Monday, 3 August 1987 16:09-EDT
From: AITG::VANROGGEN <vanroggen%aitg.decnet at hudson.dec.com>
To: common-lisp <common-lisp at su-ai.ARPA>
Re: LET-CONSTANT and DECLARE (CONSTANT
Related question: are quoted constants in compiled functions "read-only"?
How about initial values for DEFCONSTANTs?
Yes and yes. I believe that assuming that quoted constants are immutable
is widely accepted. If the inital value to defconstant is quoted,
that the constant value would also be immutable. In order to conclude
that constants are constant in the general case of an arbitrary
expression, I appeal to taste and common sense.
Rob
∂03-Aug-87 1352 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU New special form suggestion: LET-CONSTANT
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 13:52:39 PDT
Date: Mon, 3 Aug 1987 16:52 EDT
Message-ID: <BROOKS.12323617403.BABYL@MIT-OZ>
From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: barmar@THINK.COM, common-lisp@SAIL.STANFORD.EDU,
Eric Benson <edsel!kent-state!eb@LABREA.STANFORD.EDU>
Subject: New special form suggestion: LET-CONSTANT
In-reply-to: Msg of 3 Aug 1987 16:18-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
EB:
If the expression to which the variable is
bound is constant and there are no SETQs to the variable, all
references to the variable may be legitimately replaced by the
constant expression.
MOON:
It isn't an optimization in the Symbolics 3600, for most constants. The
same is true in any other machine that keeps variables in registers and
doesn't have an immediate addressing mode capable of accomodating all Lisp
constants, I believe.
Actually that's not quite true. On the 68k in Lucid lisp for instance compare
1. (let ((foo 'baz))
(setf (car x) foo))
and
2. (setf (car x) 'baz)
The symbol baz can't be represented as an immediate addressing mode. Instead
it is at some constant offset (inside any particular procedure)
from a closure pointer which is in a known register. There is a memory to memory
move on the 68k that can accomodate a source addressing mode that refers to
baz, and a destination mode that refers to (car x), assuming x is already in
a register. So case 2 takes one instruction, whereas case 1 under your description
would take two--one to move baz into the register used for foo, and one to move
that into (car x). Of course in this simple case a peephole optimizer should
be able to clean case 1 up, but if there is other intervening stuff around it
may not get it as easily as the source level transform.
So on some machines the optimization is more generally useful than your note implies.
∂03-Aug-87 1427 barmar@Think.COM New special form suggestion: LET-CONSTANT
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87 14:27:11 PDT
Received: from nietzsche by Think.COM via CHAOS; Mon, 3 Aug 87 17:25:32 EDT
Date: Mon, 3 Aug 87 17:26 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: New special form suggestion: LET-CONSTANT
To: Eric Benson <edsel!kent-state!eb@labrea.stanford.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8708031905.AA11862@kent-state.edsel.uucp>
Message-Id: <870803172620.2.BARMAR@NIETZSCHE.THINK.COM>
Date: Mon, 3 Aug 87 12:05:52 PDT
From: edsel!kent-state!eb@labrea.stanford.edu (Eric Benson)
There's actually no need for a declaration or special form. LET will
do fine all by itself. If the expression to which the variable is
bound is constant and there are no SETQs to the variable, all
references to the variable may be legitimately replaced by the
constant expression. This is a very common optimization in Lisp
compilers. However, as far as I know it is not done by the Symbolics
compiler.
I thought of that, and rejected it. I want to tell the compiler,
interpreter, and other programmers reading the code that a particular
name is a symbolic constant. If I accidentally assign to it, I want the
system to produce an error message. In Lisp this isn't a problem as
much as in my previous language, PL/I, because Lisp doesn't have call by
reference; however, I still prefer to code what I mean.
Someone else (DCP?) mentioned using MACROLET for this. I also
considered this, and almost did it. It just seemed more esthetically
unpleasing than the DEFCONSTANTs. Now, if Symbolics had SYMBOL-MACROLET
to go with their DEFINE-SYMBOL-MACRO, I could use that (my code was a
Zmail extension, so I had no reason not to use Symbolics-only features)
(actually, I don't really care for symbol macros, because they allow a
function call to masquerade as a variable reference, which is really
confusing to the reader).
barmar
∂03-Aug-87 1658 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: New special form suggestion: LET-CONSTANT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Aug 87 16:58:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 205940; Mon 3-Aug-87 19:59:39 EDT
Date: Mon, 3 Aug 87 19:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: New special form suggestion: LET-CONSTANT
To: common-lisp@sail.stanford.edu
In-Reply-To: <8708031628.AA00890@HADES.MIT.EDU>
Message-ID: <870803195934.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 03 Aug 87 12:28:38 EDT
From: <samalone@ATHENA.MIT.EDU>
It seems like a LET-CONSTANT special form....
As an alternative, I recommend a CONSTANT declaration.
The Cleanup subcommittee of X3J13 were discussing just that in May, incidental
to another proposal for language cleanup. Perhaps such a declaration is a good
idea. Presumably it would mean that the compiler is allowed to assume that the
variable is never setq'ed and the variable's value is never side-effected
(e.g. if an array, its elements are not changed and not side-effected themselves),
and the compiler is encouraged to complain if it can prove that these assumptions
are violated.
Right now that cleanup proposal is in limbo but perhaps it will get more attention
later.
∂03-Aug-87 2039 edsel!bhopal!jonl@labrea.stanford.edu compile-time processing of REQUIRE
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 20:39:25 PDT
Received: by labrea.stanford.edu; Mon, 3 Aug 87 20:26:34 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA11997; Mon, 3 Aug 87 20:18:06 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA17170; Mon, 3 Aug 87 20:15:34 PDT
Date: Mon, 3 Aug 87 20:15:34 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708040315.AA17170@bhopal.edsel.uucp>
To: labrea!snyder%hplabs@labrea.stanford.edu
Cc: labrea!common-lisp%sail@labrea.stanford.edu
In-Reply-To: Alan Snyder's message of Mon, 03 Aug 87 10:18:31 PDT <8708031718.AA03272@hplsny>
Subject: compile-time processing of REQUIRE
You've jumped ahead into another problem -- that of the pervasiveness of
the COMPILE context.
But I was talking merely about the compiler's interface -- when and where
it decides to wrap an eval-when(eval compile load) around a form. When the
user supplies his own wrapper, e.g.
(eval-when (eval load) (require "tarnation"))
then this form is not implicitly "wrapped", since the user's actions take
precedence over the implicit activity. That is, Lucid's compiler does
NOT convert the above form into anything like.
(eval-when (eval load)
(eval-when (eval compile load) (require "tarnation"))
)
I wonder if this view of "implicit wrapping" is used in other compiler?
-- JonL --
∂03-Aug-87 2317 edsel!bhopal!jonl@labrea.stanford.edu LET-CONSTANT [or "Anonymous Constants"]
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 23:17:51 PDT
Received: by labrea.stanford.edu; Mon, 3 Aug 87 23:05:15 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
id AA12283; Mon, 3 Aug 87 23:00:28 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00205; Mon, 3 Aug 87 22:57:55 PDT
Date: Mon, 3 Aug 87 22:57:55 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708040557.AA00205@bhopal.edsel.uucp>
To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Cc: bhopal!eb@labrea.stanford.edu, labrea!barmar%Think.COM@labrea.stanford.edu,
labrea!common-lisp%sail@labrea.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 3 Aug 87 16:18 EDT <870803161813.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: LET-CONSTANT [or "Anonymous Constants"]
A compiler can figure out that a local variable isn't being setq'd, and
hence can propogate through the binding as a constant literal *providing*
that it can determine that the form it is being bound to is a constant.
Admittedly, that seems to be the thrust of the messages so far -- does
common lisp need a local constant declaration for variables -- and I
think the answer is, as you phrase it, "no, because any information that
such a declaration provides can equally well be discerned mechanically
by the compiler."
But I see the need for a local constant declaration for random expressions
apart from the issue of properties of program variables. "Anonymous
Constants", if you will. Consider for example Interlisp's [special-form]
function CONSTANT:
(let ((x (constant `(JonL-phone-no ,(call-up-bell-tel-co)))))
(check-phone-book x)
(broadcast-to-friends x (constant (figger-out-broadcast-routing)))
x)
Without the very-local "declaration" provided by 'constant', the compiler
would be obliged NOT to propogate the binding value of x, and not to
elide the runtim calls to 'call-up-bell-tel-co', 'list', and the totally
random 'figger-out-broadcast-routing'. [And also not to create the list in
a static, or read-only area, etc.]
Using 'constant' rather than #. is more of an issue in Interlisp style
-- the "residential" style as opposed to the EMACS style -- but I don't
think it should be ignored in CL. In fact, a later addition to Interlisp
was 'loadtimeconstant', which is a functionality that has been under active
discussion on this mailing list in recent weeks.
-- JonL --
∂04-Aug-87 1057 @DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM New special form suggestion: LET-CONSTANT
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 4 Aug 87 10:57:23 PDT
Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110013; Mon 3-Aug-87 12:30:09 EDT
Date: Mon, 3 Aug 87 12:29 EDT
From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>
Subject: New special form suggestion: LET-CONSTANT
To: barmar@Think.COM, common-lisp@sail.stanford.edu
In-Reply-To: <870803120736.7.BARMAR@NIETZSCHE.THINK.COM>
Message-ID: <870803122946.7.CYPHERS@RAVEN.S4CC.Symbolics.COM>
Date: Mon, 3 Aug 87 12:07 EDT
From: Barry Margolin <barmar@Think.COM>
Today I noticed myself creating DEFCONSTANTS for symbolic constants that
would only be used by the one function I was writing. It struck me that
they really wanted to be local to the function, not top-level variables,
but I wanted to make sure that the compiler would open-code them, and I
also wanted to declare their constantness to readers. There is
currently no way to do this in Common Lisp (nor, as far as I know, in
Symbolics Common Lisp, which I was using) without DEFCONSTANT, which
also creates a useless special variable.
It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list
keyword, would be the right thing for this. LET-CONSTANT would be to
DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to
&AUX.
I think a CONSTANT declaration would be better than a new special form.
It would be the value cell equivalent of the INLINE declaration for
functions.
Actually, for consistency with the names FLET and MACROLET, I suppose
this should be called CONSTANTLET (although to me that seems like the
word for a little constant). However, I never liked those names anyway.
barmar@think.com
∂06-Aug-87 0721 SOLEY@XX.LCS.MIT.EDU New special form suggestion: LET-CONSTANT
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 87 07:21:42 PDT
Date: Thu, 6 Aug 1987 10:18 EDT
Message-ID: <SOLEY.12324332217.BABYL@XX.LCS.MIT.EDU>
From: SOLEY@XX.LCS.MIT.EDU
To: Barry Margolin <barmar@THINK.COM>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: New special form suggestion: LET-CONSTANT
In-reply-to: Msg of 3 Aug 1987 12:07-EDT from Barry Margolin <barmar at Think.COM>
Date: Monday, 3 August 1987 12:07-EDT
From: Barry Margolin <barmar at Think.COM>
Today I noticed myself creating DEFCONSTANTS for symbolic constants that
would only be used by the one function I was writing.
A declaration would be much cleaner; you could still write let-constant
(or constantlet) in terms of it, as well as defconstant for that matter
[(proclaim '(constant ...))].
It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list
keyword, would be the right thing for this. LET-CONSTANT would be to
DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to
&AUX.
Yeah, and how about an &LOGOUT lambda-list keyword, to log out the current
process? Really, although I understand the trivial difference in scope
between LET and &AUX, do we need to continue adding random lambda-list
keywords, which (worse yet) aren't keywords at all?
-- Richard
∂06-Aug-87 0809 gls@Think.COM New special form suggestion: LET-CONSTANT
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 6 Aug 87 08:09:24 PDT
Return-Path: <gls@Think.COM>
Received: from boethius by Think.COM via CHAOS; Thu, 6 Aug 87 11:08:41 EDT
Date: Thu, 6 Aug 87 11:11 EDT
From: Guy Steele <gls@Think.COM>
Subject: New special form suggestion: LET-CONSTANT
To: SOLEY@xx.lcs.mit.edu, barmar@Think.COM
Cc: common-lisp@sail.stanford.edu, gls@Think.COM
In-Reply-To: <SOLEY.12324332217.BABYL@XX.LCS.MIT.EDU>
Message-Id: <870806111111.3.GLS@BOETHIUS.THINK.COM>
Date: Thu, 6 Aug 1987 10:18 EDT
From: SOLEY@xx.lcs.mit.edu
Date: Monday, 3 August 1987 12:07-EDT
From: Barry Margolin <barmar at Think.COM>
...
It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list
keyword, would be the right thing for this. LET-CONSTANT would be to
DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to
&AUX.
Yeah, and how about an &LOGOUT lambda-list keyword, to log out the current
process? Really, although I understand the trivial difference in scope
between LET and &AUX, do we need to continue adding random lambda-list
keywords, which (worse yet) aren't keywords at all?
Oh, wow! I don't mean to make fun of anyone, but you just gave me
a great idea for eliminating LOOP by folding it into LAMBDA.
(JONL, are you listening? That old idea resurfaces in new syntax.)
(defun factorial (n &for j &from 1 &to n &for a &= 1 &then (* a j) &finally (return a)))
A great feature of this is that it defuses the old quibble of
whether or not LOOP "keywords" should be :-keywords by making
them be &-keywords.
We can get declarations in this way, too.
(defun factorial (n &integer n
&for j &from 1 &to n
&for a &= 1 &then (* a j)
&integer j a
&finally (return a)))
Also, let's do for English as for Lisp and replace documentation
strings. What's sauce for the goose is sauce for the gander.
(defun factorial (n &integer n
&for j &from 1 &to n
&for a &= 1 &then (* a j)
&integer j a
&finally (return a))
&documentation &factorial &takes &a &nonnegative
&integer &n &and &returns &the &product &of
&all &positive &integers ¬ &greater
&than &n &.)
&Maybe &I &could &get &to &like &this &language &after &all &.
--Quux
∂06-Aug-87 1308 sandra%orion@cs.utah.edu truename, merge-pathnames, etc.
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 87 13:08:44 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA29865; Thu, 6 Aug 87 14:11:17 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA16097; Thu, 6 Aug 87 14:11:14 MDT
Date: Thu, 6 Aug 87 14:11:14 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8708062011.AA16097@orion.utah.edu>
Subject: truename, merge-pathnames, etc.
To: common-lisp@sail.stanford.edu
I'm having a problem with incorrect expansion of pathnames under VMS, when
logical names are used. The problem happens when I, or the Lisp runtime, does
something like
(merge-pathnames "LIBRARY:" *default-pathname-defaults*)
My logical name "LIBRARY:" is likely to translate to a string that supplies
both a device and directory. However, the Lisp doesn't do the translation and
is instead pulling the directory from *default-pathname-defaults*, with the
end result that it builds up a pathname pointing to the wrong place. I can't
use TRUENAME to force translation of the logical name first, because it
complains about not being able to find a file that matches the incomplete
specification. And, I can't build up a complete file specification to give
to TRUENAME because of the other problem. Perhaps we need another function
like TRUENAME that just does the name translation without checking to see
that the file exists?
-Sandra
-------
∂06-Aug-87 1612 RWK@YUKON.SCRC.Symbolics.COM truename, merge-pathnames, etc.
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 6 Aug 87 16:12:06 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 246352; Thu 6-Aug-87 19:07:56 EDT
Date: Thu, 6 Aug 87 19:07 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: truename, merge-pathnames, etc.
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8708062011.AA16097@orion.utah.edu>
Message-ID: <870806190756.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 6 Aug 87 14:11:14 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
I'm having a problem with incorrect expansion of pathnames under VMS, when
logical names are used. The problem happens when I, or the Lisp runtime, does
something like
(merge-pathnames "LIBRARY:" *default-pathname-defaults*)
My logical name "LIBRARY:" is likely to translate to a string that supplies
both a device and directory. However, the Lisp doesn't do the translation and
is instead pulling the directory from *default-pathname-defaults*, with the
end result that it builds up a pathname pointing to the wrong place. I can't
use TRUENAME to force translation of the logical name first, because it
complains about not being able to find a file that matches the incomplete
specification. And, I can't build up a complete file specification to give
to TRUENAME because of the other problem. Perhaps we need another function
like TRUENAME that just does the name translation without checking to see
that the file exists?
-Sandra
-------
This is what :UNSPECIFIC as a pathname component is good for.
(Not that we implement it in this particular case, either).
The people who borrowed the Symbolics pathname system for
Common Lisp emasculated it without understanding it.
The idea is that if a pathname *isn't supposed to have* certain
components, then you use :UNSPECIFIC. If they're just not supplied
yet, use NIL. Then MERGE-PATHNAMES can figure out the right thing
to do for itself.
Of course, this moves the burden onto the shoulders of PARSE-PATHNAME.
For UNIX pathnames (distinguishing between "foo", and "foo.", and
"foo" with no type specified yet), this is apparent from the syntax.
Since the designers of VMS didn't choose to make their pathname syntax
independent of run-time context (boo, hiss!), PARSE-PATHNAME has to
be able to ask the operating system what logical pathname translations
are in effect at the time.
The pathname section of CLtL is full of gotcha's like this. It is
in need of some serious cleanup.
∂07-Aug-87 2215 @RELAY.CS.NET:HELLER@cs.umass.edu RE: truename, merge-pathnames, etc.
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 7 Aug 87 22:15:09 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ad05638; 8 Aug 87 1:12 EDT
Received: from cs.umass.edu by RELAY.CS.NET id ak07820; 8 Aug 87 1:04 EDT
Date: Fri, 7 Aug 87 09:06 EDT
From: Stride 440 User <HELLER%cs.umass.edu@RELAY.CS.NET>
Subject: RE: truename, merge-pathnames, etc.
To: Common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-lisp@SAIL.STANFORD.EDU"
>From: IN%"Sandra J Loosemore <sandra%orion@CS.UTAH.EDU>" 7-AUG-1987 04:58
>Subj: truename, merge-pathnames, etc.
>
>I'm having a problem with incorrect expansion of pathnames under VMS, when
>logical names are used. The problem happens when I, or the Lisp runtime, does
>something like
>
> (merge-pathnames "LIBRARY:" *default-pathname-defaults*)
>
>My logical name "LIBRARY:" is likely to translate to a string that supplies
>both a device and directory. However, the Lisp doesn't do the translation and
>is instead pulling the directory from *default-pathname-defaults*, with the
>end result that it builds up a pathname pointing to the wrong place. I can't
>use TRUENAME to force translation of the logical name first, because it
>complains about not being able to find a file that matches the incomplete
>specification. And, I can't build up a complete file specification to give
>to TRUENAME because of the other problem. Perhaps we need another function
>like TRUENAME that just does the name translation without checking to see
>that the file exists?
>
>-Sandra
>-------
>
Hm... What version of VAX-LISP are you using? I just did some tests and it
actually works ok for me:
Lisp> (translate-logical-name "LLVS")
("LLVS$DISK:[LLVS]")
Lisp> (merge-pathnames "LLVS:" *default-pathname-defaults*)
#S(pathname :host "VAX9" :device "VIS3$DISK" :directory "LLVS" :name nil
:type nil :version :newest)
Lisp> *default-pathname-defaults*
#S(pathname :host "VAX9" :device "VIS$DISK"
:directory "HELLER.VISION.NEW_SYSTEM" :name nil :type nil
:version nil)
For completeness I also tried:
Lisp> (merge-pathnames (pathname "LLVS:") *default-pathname-defaults*)
#S(pathname :host "VAX9" :device "VIS3$DISK" :directory "LLVS" :name nil
:type nil :version :newest)
I think the last version is probably safest, since it forces the logical
name to be processed into a proper pathname. There is still a problem with
search lists (logical names with a list of values). For that you probably
should not use merge-pathnames at all - instead use concatenate to create an
un-parsed filename string and use probe-file to fetch the actual path.
(Probe-file correctly handle search lists, since it calls RMS to search
for the file (probably with a SYS$SEARCH call).)
BTW: we are running VMS 4.5 and VAX-LISP U2.2 (yes we are a field test
site).
Robert Heller
ARPANet: Heller@CS.UMass.EDU
BITNET: Heller@UMass.BITNET
BIX: Heller
GEnie: RHeller
FidoNet: 321/148 (Locks Hill BBS, Wendell, MA)
CompuServe 71450,3432
Local PV VAXen: COINS::HELLER
UCC Cyber/DG: Heller@CS
∂08-Aug-87 0858 sandra%orion@cs.utah.edu RE: truename, merge-pathnames, etc.
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 87 08:58:21 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA03714; Sat, 8 Aug 87 10:00:58 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA21647; Sat, 8 Aug 87 10:00:54 MDT
Date: Sat, 8 Aug 87 10:00:54 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8708081600.AA21647@orion.utah.edu>
To: HELLER%cs.umass.edu@relay.cs.net
Cc: common-lisp@sail.stanford.edu
Subject: RE: truename, merge-pathnames, etc.
News-Path: utah-cs!@SAIL.STANFORD.EDU,@RELAY.CS.NET:HELLER@cs.umass.edu
References: <8708080541.AA18042@cs.utah.edu>
Actually, I was having the problem with Lucid Lisp. VaxLisp does
indeed handle logical names in a "reasonable" manner, but after
rereading CLtL I've decided that its behavior is probably technically
incorrect, and that Lucid's behavior is correct. That is, CLtL implies
that PARSE-NAMESTRING and MERGE-PATHNAMES are only supposed to operate
on pathname *syntax* without regard to the *semantics* attached to the
various components by the underlying file system. Translation is
mentioned only in the context of TRUENAME.
Your idea with concatenating and using probe-file won't work either,
first of all because it's nonportable (the whole reason for having the
pathname functions in the first place is to avoid this kind of
operation), and secondly because I may be trying to build the name of a
file that doesn't exist yet.
Also, this problem is not specific to VMS. You can get into the same
problem under Un*x if your Lisp supports the use of environment variables
or shell variables in filenames.
-Sandra
∂08-Aug-87 1347 RAM@C.CS.CMU.EDU truename, merge-pathnames, etc.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 87 13:46:53 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 8 Aug 87 16:46:33-EDT
Date: Sat, 8 Aug 1987 16:46 EDT
Message-ID: <RAM.12324927073.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: truename, merge-pathnames, etc.
In-reply-to: Msg of 6 Aug 1987 16:11-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
In CMU Common Lisp, we have hacked around these problems by playing
with the rules for filename parsing. Although the result may be
somewhat nonintuitive, it is legal common Lisp, since the
namestring => pathname translation is not specified. Parse-Namestring
contrives to translate pathnames so that Merge-Pathnames "works
right". This is mostly done by by sticking special values in the
pathname, and is probably similar to the notion of :Unspecified.
For example, we get around to problem you mention by having:
(pathname-device "foo:") => #()
That is, a namestring that specifies only a device is translated so as
to make explcit that a directory is being specified as well. The
directory has no components, so NAMESTRING translates back to the
original namestring, but merging of other directories in inhibited.
We are currently running on a Unix filesystem. Since Unix has no
notion of devices or logical names, we use the pathname device field
for a "search list" mechanism that is implemented by Lisp. If we were
on a filesystem where devices meant anything, then this hack probably
wound't work so well.
There are also some other cases in which merging is inhibited by the
appropriate namestring translation:
(pathname-device "/foo/") => :ABSOLUTE
(pathname-device "foo/") => "Default"
(pathname-type "foo.") => ""
I agree that Common Lisp should address this, and think that a general
solution would be appropriate, but it is possible in many cases to do
the right thing within the constraints of the current MERGE-PATHNAMES
definition by tweaking the namestring translation.
Rob
∂09-Aug-87 1439 tsf@theory.cs.cmu.edu Continuation Passing Style?
Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Aug 87 14:39:07 PDT
Date: Sunday, 9 August 1987 17:40:16 EDT
From: Timothy.Freeman@theory.cs.cmu.edu
To: common-lisp@sail.stanford.edu
Subject: Continuation Passing Style?
Message-ID: <1987.8.9.21.29.37.Timothy.Freeman@theory.cs.cmu.edu>
Does anyone have any code to transform some subset of Common Lisp into
continuation passing style? How about some idea of what that subset
would have to be?
If you have a response, please mail it to me as well as the mailing
list, because I no longer read this mailing list.
∂10-Aug-87 1216 wile@vaxa.isi.edu Test suite available
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 87 12:16:03 PDT
Posted-Date: Mon, 10 Aug 87 12:16:23 PDT
Message-Id: <8708101916.AA00282@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA00282; Mon, 10 Aug 87 12:16:28 PDT
To: COMMON-LISP@sail.stanford.edu
From: wile@vaxa.isi.edu
Subject: Test suite available
Date: Mon, 10 Aug 87 12:16:23 PDT
Sender: wile@vaxa.isi.edu
Folks--
A Common Lisp Validation Suite has been assembled here at ISI by Richard
Berman. He essentially developed a test driver and has converted
portions of the suites of some of the vendors to his format. The suite
contains only a small fraction of the tests he has received, but it is a
start for anyone responsible for quality assurance of CL
implementations.
Unfortunately for us, Richard resigned recently (to go off and become a
recording star and/or AI in music guru), so there will be little
additional support or development until a replacement for him is found.
Although several of you are aware of the existence of this suite, we
have been told that many interested parties were not; hence, this
message. To access the suite, ftp to venera.isi.edu logging in as
anonymous. Please respond with your name and affiliation as the
password. The two directories of interest are: /usr/ftp/Valid-Code/*.*
and /usr/ftp/Valid-Tests/*.*. (Capitalization is necessary.) The file
README.NOW contains the information necessary to understand how to
invoke the test suite and what files to transfer to your machine.
Apparently around 400 tests are available now.
We have no way to monitor the activity on the files, except with the ftp
log of your anonymous password. We would very much appreciate hearing
about any successes, problems, or suggestions (perhaps as to which
remaining tests to convert first) you have. Send mail to
WILE@VAXA.ISI.EDU for now.
Testily yours,
Dave Wile
USC/ Information Sciences Institute
(213) 822-1511
∂17-Aug-87 0054 GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU FLET & declarations
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Aug 87 00:54:33 PDT
Date: Mon 17 Aug 87 03:57:47-EDT
From: GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Subject: FLET & declarations
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12327146435.14.GZ@OZ.AI.MIT.EDU>
Are 'pervasive' declarations in FLET supposed to apply to the function bodies?
E.g.
(flet ((foo () x)) ;Is this x special?
(declare (special x))
...)
(flet ((foo () (foo) ...)) ;Does this call to (foo) return a fixnum?
(declare (function foo () fixnum))
...)
(flet ((foo () (foo 17))) ;Is (foo 17) inline?
(declare (inline foo))
...)
-------
∂18-Aug-87 0902 mike%acorn%LIVE-OAK.LCS.MIT.EDU@XX.LCS.MIT.EDU Question on function type spec and lambda-list keywords
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 87 09:02:15 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 18 Aug 87 12:02-EDT
Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 55991; 18 Aug 87 11:56:15-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 78425; Tue 18-Aug-87 11:39:11-EDT
Date: Tue, 18 Aug 87 11:44 est
From: mike%acorn@oak.lcs.mit.edu
To: RpK%acorn@oak.lcs.mit.edu
Subject: Question on function type spec and lambda-list keywords
Cc: common-lisp@sail.stanford.edu
Date: Mon, 3 Aug 87 12:39 EDT
From: RpK%acorn@oak.lcs.mit.edu
Is the ftype of +
(function (&rest number) number)
or
(function (&rest list) number)
?
I would assume the former (since &rest args are always of type list), but
there aren't any examples in CLtL that make this clear.
This seems a bit wierd, but I'd assume the latter, since
(function (&rest (list-of number)) number)
seems right. Unfortunately, common lisp's type language doens't
allow parameterized types of this sort, so you can't really express this.
Other programming languages allow this sort of type construction.
You could do:
(deftype list-of-number ()
`(satisfies list-of-number-p))
(defun list-of-number-p (x)
(or (null x)
(and (consp x)
(numberp (car x))
(list-of-number-p (cdr x))))
Then,
(proclaim '(ftype + (function (&rest list-of-number) number)))
since we're using "satisfies" here, I don't see how this could
be useful tho.
...mike beckerle
Gold Hill
∂18-Aug-87 1328 Moon@STONY-BROOK.SCRC.Symbolics.COM FLET & declarations
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Aug 87 13:28:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 215806; Tue 18-Aug-87 16:28:17 EDT
Date: Tue, 18 Aug 87 16:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FLET & declarations
To: GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <12327146435.14.GZ@OZ.AI.MIT.EDU>
Message-ID: <870818162759.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon 17 Aug 87 03:57:47-EDT
From: GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Are 'pervasive' declarations in FLET supposed to apply to the function bodies?
E.g.
(flet ((foo () x)) ;Is this x special?
(declare (special x))
...)
(flet ((foo () (foo) ...)) ;Does this call to (foo) return a fixnum?
(declare (function foo () fixnum))
...)
(flet ((foo () (foo 17))) ;Is (foo 17) inline?
(declare (inline foo))
...)
CLtL does not permit DECLARE to be used in that position (see p.113).
I believe it has been proposed to change that, although I couldn't
find a copy of the proposal in my rather disorganized files. I would
argue that the paragraph in the middle of page 155 of CLtL supports
the position that when this extension is made, the pervasive declarations
should apply to the function bodies.
Note that the FUNCTION declaration used in your middle example is not
pervasive. Since you use FLET rather than LABELS, this declaration
would not apply to the call to FOO within the body of FOO. It's a
different FOO.
The INLINE declaration is said by CLtL to be pervasive, however I
believe that to be a bug since it makes it unclear which of the two
FOOs in your example it refers to. Perhaps it refers to both.
Anyone putting together a proposal to clean up the specification of
declarations in Common Lisp ought to address the issues raised by
your question.
∂24-Aug-87 0628 unido!ztivax!kolb@seismo.CSS.GOV Interpretation of shadowing
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 24 Aug 87 06:28:20 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA04764; Mon, 24 Aug 87 09:28:24 EDT
Received: by unido.uucp with uucp;
Mon, 24 Aug 87 14:52:38 +0100
From: "Dieter Kolb" <unido!ztivax!kolb@seismo.CSS.GOV>
Date: Mon, 24 Aug 87 14:50:37 -0100
Message-Id: <8708241350.AA23968@ztivax.uucp>
Received: by ztivax.uucp; Mon, 24 Aug 87 14:50:37 -0100
To: Common-lisp@sail.stanford.edu
Subject: Interpretation of shadowing
Cc: unido!Dieter@seismo.CSS.GOV, unido!Kolb@seismo.CSS.GOV
CLtL describes in section 11.5, page 180 a name conflict problem by
applying the function use-package. The name conflict is between a symbol
directly present in the using package and an external symbol of the used
package. This name conflict may be resolved in favor of the symbol
directly present in the using package by making it a shadowing symbol.
However, CLtL gives no advice how that should be done.
In our understanding the function shadow should be used to resolve this
name conflict.
However the function shadow has no effect, if the symbol is already
present in the package (CLtL, section 11.7). So, following CLtL, this
could not be the solution. Therefore, we investigated some other CL
implementations:
Lucid Common LISP on Apollo DOMAIN as well as Xerox LISP:
The name conflict can be resolved by using the function shadowing-import
SPICE LISP:
The functionality of the function shadow in SPICE LISP is extended.
shadow works also if the symbol is already present. So, the name
conflict can be resolved by using the function shadow. (However, shadow
works different as described in CLtL.)
Kyoto Common Lisp on VAX:
shadow works as described in CLtL. The name conflict cannot be resolved
in this system.
How should CLtL be interpreted with respect to this problem?
Dieter Kolb
∂24-Aug-87 0753 samalone@ATHENA.MIT.EDU Re: Interpretation of shadowing
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Aug 87 07:53:01 PDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA18770; Mon, 24 Aug 87 10:52:55 EDT
From: <samalone@ATHENA.MIT.EDU>
Received: by HADES.MIT.EDU (5.45/4.7) id AA28748; Mon, 24 Aug 87 10:51:46 EDT
Message-Id: <8708241451.AA28748@HADES.MIT.EDU>
To: "Dieter Kolb" <unido!ztivax!kolb@seismo.CSS.GOV>
Cc: common-lisp@sail.stanford.edu
Subject: Re: Interpretation of shadowing
In-Reply-To: Your message of Mon, 24 Aug 87 14:50:37 -0100.
<8708241350.AA23968@ztivax.uucp>
Date: Mon, 24 Aug 87 10:51:44 EDT
CLtL describes in section 11.5, page 180 a name conflict
problem by applying the function use-package. The name
conflict is between a symbol directly present in the using
package and an external symbol of the used package. This name
conflict may be resolved in favor of the symbol directly
present in the using package by making it a shadowing symbol.
However, CLtL gives no advice how that should be done.
In our understanding the function shadow should be used to
resolve this name conflict.
However the function shadow has no effect, if the symbol is
already present in the package (CLtL, section 11.7). So,
following CLtL, this could not be the solution...
I understand your confusion. I believe that the problem is due to an
ambiguity in the definition of SHADOW given in CLtL. (Someone on the cleanup
committee should correct me if I'm wrong.) Unfortunately, many Common Lisp
implementers have taken the wrong interpretation of this section of the
manual, and so propagated the confusion on to their users.
You are correct that SHADOW should be used to resolve the name conflict you
described. Interpreted correctly, CLtL describes a SHADOW function that _is_
capable of resolving the name conflict.
When CLtL says that "If such a symbol is present in this package, nothing is
done", this is intended to contrast only with the following sentence, which
says "Otherwise, a new symbol is created with this print name..." The next
sentence that says "The symbol is also placed on the shadowing-symbols list of
package" applies regardless of whether such a symbol is present in this
package or not.
Given this interpretation, SHADOW has an effect whether the symbol is already
present in the package or not (unless it is already a shadowing symbol), and
so is the correct way to resolve the name conflict you described. From the
descriptions you provided, it sounds like the SPICE LISP implementers did the
right thing.
--Stuart A. Malone
∂24-Aug-87 1111 Moon@STONY-BROOK.SCRC.Symbolics.COM Interpretation of shadowing
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:11:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219204; Mon 24-Aug-87 14:07:36 EDT
Date: Mon, 24 Aug 87 14:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Interpretation of shadowing
To: Dieter Kolb <unido!ztivax!kolb@seismo.CSS.GOV>, samalone@ATHENA.MIT.EDU
cc: Common-lisp@sail.stanford.edu
In-Reply-To: <8708241350.AA23968@ztivax.uucp>,
<8708241451.AA28748@HADES.MIT.EDU>
Message-ID: <870824140704.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with Malone. The SHADOW function always adds the symbol
to the PACKAGE-SHADOWING-SYMBOLS list, and the informal wording
on p.186 of CLtL should not be interpreted otherwise.
This does not seem to be on the cleanup subcommittee's agenda yet,
so I'll add a writeup of the issue. Thanks for pointing it out.
∂24-Aug-87 1123 dml@NADC.ARPA The values returned by SETF
Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:22:53 PDT
Received: by NADC.ARPA (5.51/1.0 )
id AA20419; Mon, 24 Aug 87 14:25:04 EDT
Date: Mon, 24 Aug 87 14:25:04 EDT
From: dml@nadc.arpa (D. Loewenstern)
Message-Id: <8708241825.AA20419@NADC.ARPA>
To: common-lisp@sail.stanford.edu
Subject: The values returned by SETF
Cc: dml@NADC.ARPA
Is the value returned by SETF defined in general, for all standard get/put functions?
Specifically, what is returned by (SETF (VALUES IGNORE X) (VALUES 1 2))?
Gold Hill's GCLISP (LM version) seems to return 1 when evaled but NIL when compiled.
David Loewenstern
Naval Air Development Center
code 7013
Warminster, PA 18974-5000
<dml@nadc.arpa>
∂24-Aug-87 1148 Moon@STONY-BROOK.SCRC.Symbolics.COM The values returned by SETF
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:47:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219303; Mon 24-Aug-87 14:48:12 EDT
Date: Mon, 24 Aug 87 14:47 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: The values returned by SETF
To: D. Loewenstern <dml@NADC.ARPA>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8708241825.AA20419@NADC.ARPA>
Message-ID: <870824144731.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 24 Aug 87 14:25:04 EDT
From: dml@nadc.arpa (D. Loewenstern)
Is the value returned by SETF defined in general, for all standard get/put functions?
Specifically, what is returned by (SETF (VALUES IGNORE X) (VALUES 1 2))?
SETF returns the values of its last subform (CLtL p.97).
SETF of VALUES is an extension to Common Lisp, but that shouldn't change the
rules for what SETF returns.
∂24-Aug-87 1204 093725%incdp1@LANL.GOV New Address for Common Lisp
Received: from LANL.GOV by SAIL.STANFORD.EDU with TCP; 24 Aug 87 12:04:35 PDT
Received: by LANL.GOV (5.54/1.14)
id AA28950; Mon, 24 Aug 87 13:02:21 MDT
Date: Mon, 24 Aug 87 13:02:21 MDT
Message-Id: <8708241902.AA28950@LANL.GOV>
From: 093725%incdp1@LANL.GOV (TOM NORRIS)
To: common-lisp@sail.stanford.edu
Subject: New Address for Common Lisp
Common_Iisp:
I have a new mailing address for receiving mail from the Common-lisp. The
old address was: 093725%incdp1.xnet@lanl.gov
The new address is:
tln@beta.lanl.gov
Thank-you
Tom Norris
Los Alamos National Lab.
505-667-4630
∂24-Aug-87 1310 Pavel.pa@Xerox.COM Re: The values returned by SETF
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Aug 87 13:09:50 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 AUG 87 13:07:49 PDT
Date: Mon, 24 Aug 87 13:07:36 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: The values returned by SETF
In-reply-to: <8708241825.AA20419@NADC.ARPA>
To: dml@nadc.arpa (D. Loewenstern)
Cc: common-lisp@sail.stanford.edu
Message-ID: <870824-130749-7757@Xerox>
Specifically, what is returned by
(SETF (VALUES IGNORE X) (VALUES 1 2))?
Common Lisp does not define the behaviour of SETF of VALUES. Do you
have a question about one of the ccases that IS defined?
Pavel
∂25-Aug-87 0713 RAM@C.CS.CMU.EDU The values returned by SETF
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 87 07:13:37 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 25 Aug 87 10:13:02-EDT
Date: Tue, 25 Aug 1987 10:12 EDT
Message-ID: <RAM.12329311876.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SAIL.STANFORD.EDU, "D. Loewenstern" <dml@NADC.ARPA>
Subject: The values returned by SETF
In-reply-to: Msg of 24 Aug 1987 14:47-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Date: Monday, 24 August 1987 14:47-EDT
From: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
To: D. Loewenstern <dml at NADC.ARPA>
Re: The values returned by SETF
Date: Mon, 24 Aug 87 14:25:04 EDT
From: dml@nadc.arpa (D. Loewenstern)
Is the value returned by SETF defined in general, for all
standard get/put functions?
Specifically, what is returned by (SETF (VALUES IGNORE X)
(VALUES 1 2))?
SETF returns the values of its last subform (CLtL p.97).
Actually, it says "the ultimate result of evaluating the setf form is
the value of newvalue." I would interpret your restatement to mean
that it has to return all the values of the newvalue form. I can't
see how you can do this in a Common Lisp macro without using
Multiple-Value-List. At least in our implementation:
(setf foo (values 1 2 3)) => 1
I would guess that the actual rule is that setf returns the number of
values that the setf method was expecting (supposing that the setf
method writer bothers to return the right value(s)).
Rob
∂25-Aug-87 1201 edsel!bhopal!jonl@labrea.stanford.edu Interpretation of shadowing [and type of argument to SHADOW]
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 87 12:01:51 PDT
Received: by labrea.stanford.edu; Tue, 25 Aug 87 11:42:33 PDT
Received: from bhopal.edsel.com by edsel.uucp (3.2/SMI-2.0)
id AA05644; Tue, 25 Aug 87 11:50:54 PDT
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA15097; Tue, 25 Aug 87 11:51:21 PDT
Date: Tue, 25 Aug 87 11:51:21 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708251851.AA15097@bhopal.edsel.com>
To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Cc: labrea!unido!ztivax!kolb%seismo.CSS.GOV@labrea.stanford.edu,
labrea!samalone%ATHENA.MIT.EDU@labrea.stanford.edu,
labrea!Common-lisp%sail@labrea.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 24 Aug 87 14:07 EDT <870824140704.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Interpretation of shadowing [and type of argument to SHADOW]
re: ... The SHADOW function always adds the symbol
to the PACKAGE-SHADOWING-SYMBOLS list, and the informal wording
on p.186 of CLtL should not be interpreted otherwise.
At Lucid (against our better instincts!) we followed the "letter of the
law" on page 186. That phraseology is certainly misguided, but not exactly
ambiguous:
"If <condition A is true>, then nothing is done.
Otherwise, <step B is taken>. [And]... also <step C is taken>."
I say, "not ambiguous" because the sentence
"[And]... also <step C is taken>"
only parses in the context of "something having been done", so that
<step C> is done ALSO, or "in addition" to that "something".
However, that behaviour -- even if mandated by CLtL -- is not productive,
and I would very much like to see it redefined.
On the other hand, this glitch hasn't been the source of the most serious
problem with SHADOW. The fact that it's argument is a symbol, which it
immediately discards after extracting the symbol-name, has caused a very
subtle bug in virtually every implementation's compiled-code format. To
avoid this bug, I would like to see SHADOW changed to take strings as
arguments, rather than symbols. More realistically, it should at least be
permitted to take strings as well as symbols so that one can avoid the
lossage evident in the following example.
Consider the file:
(in-package "FOO")
(shadow 'bar) ;maybe this BAR is inherited from LISP?
(print (symbol-package 'bar)) ;but this BAR should be only in FOO.
How will the call to shadow be compiled when BAR is already present in FOO
as an internal shadowing symbol? Now consider how that compiled file will
load into a runtime environment whose package structure is DIFFERENT from
that of the compile-time environment in the critical aspect that BAR is not
present in the FOO package (much less being present as a shadowing symbol).
Admittedly, CLtL give the user no guarantees if he doesn't arrange to have
his runtime package environment "the same" as the compile time one; but this
scenario is a very common, forgivable one. It will happen if you compile a
file twice (from the same Lisp image), and then load the result into a fresh
Lisp image.
At least one Common Lisp implementation has it's compiler recognize
top-level calls to shadow and compile them specially. But this is
a fix only for the specific situation of top-level calls, not for a
call like:
(in-package "FOO)
(funcall (if (probably-true)
#'shadow
#'print)
'bar) ;maybe this BAR is inherited from LISP?
(print (symbol-package 'bar)) ;but this BAR should be only in FOO.
A much better solution would be to allow the author of this code to write:
(in-package "FOO)
(funcall (if (probably-true)
#'shadow
#'print)
"BAR") ;No question about this "BAR" !
(print (symbol-package 'bar)) ;and this BAR should be only in FOO.
instead.
-- JonL --
P.S. Please, no discussion on why (if (probably-true) #'shadow #'print))
is a useless line of code. I picked it only to illustrate that this
particular SHADOW problem isn't completely solved by having the
compiler statically re-write the user's code.
∂25-Aug-87 1354 Moon@STONY-BROOK.SCRC.Symbolics.COM Interpretation of shadowing [and type of argument to SHADOW]
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Aug 87 13:54:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 220537; Tue 25-Aug-87 16:52:56 EDT
Date: Tue, 25 Aug 87 16:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Interpretation of shadowing [and type of argument to SHADOW]
To: Jon L White <edsel!bhopal!jonl@labrea.stanford.edu>
cc: Common-lisp@sail.stanford.edu
In-Reply-To: <8708251851.AA15097@bhopal.edsel.com>
Message-ID: <870825165230.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 25 Aug 87 11:51:21 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
I would like to see SHADOW changed to take strings as
arguments, rather than symbols. More realistically, it should at least be
permitted to take strings as well as symbols.
You're right of course.
A close reading of CLtL shows that one can already use (shadow '#:bar)
in place of (shadow 'bar), to achieve much the same effect as (shadow "bar").
But the user should not have to play such games, strings should be accepted.
Current practice: shadow already accepts strings in Symbolics Common Lisp.
∂25-Aug-87 1527 @DOUGHNUT.CS.ROCHESTER.EDU:miller@DOUGHNUT.CS.ROCHESTER.EDU SHADOW et. al
Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 25 Aug 87 15:26:46 PDT
Date: Tue, 25 Aug 87 18:23 EDT
From: Brad Miller <miller@DOUGHNUT.CS.ROCHESTER.EDU>
Subject: SHADOW et. al
To: common-lisp@sail.stanford.edu
Message-ID: <870825182322.3.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Default-Character-Style: (:FIX :CONDENSED :NORMAL)
Fonts: CPTFONTC
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: Computer Science Department, University of Rochester, Rochester NY 14627
Phone: Currently: 716-275-7747 After 1 Sept. also try: 716-275-1118
Actually this discussion of shadow brings to mind a problem I have had with CL
packages, which deals with just what symbol you get...
Lets presume that the symbol FOO exists in 3 places, packages A B and C...
I create package D which will :USE A B C.
Which foo does it get? well, probably it will complain, and force you to
shadowing-import one of them. What I would sort of like to see (others
probably know more about the issues here than I do) is that the USE list of a
package is also the order in which the packages are searched to resolve symbol
references. Thus in the above example, a reference to FOO in D would be
resolved as A::FOO with *no complaint* about the duplicates in B and C.
For debugging purposes, there can be some special the package system uses to
complain about duplicates as in the above, what I want is a mechanism such
that there is a default, normal, behavior for such things, which allows this
duplication.
Brad Miller
------
miller@cs.rochester.edu {...[allegra|seismo]!rochester!miller}
Brad Miller
University of Rochester Computer Science Department
NOTE: Our computers will be down the first week of September to be
moved to a new home. If mail should fail, please retry. TKS!
∂27-Aug-87 1239 DALY@IBM.COM length
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 27 Aug 87 12:39:32 PDT
Date: 27 August 1987, 14:14:28 EDT
From: Timothy Daly <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <082787.141428.daly@ibm.com>
Subject: length
Is (LENGTH '(3 . 3)) an error?
Lucid Common returns 1.
Symbolics Common returns error.
The bible states:
p248: length takes a sequence
p245: sequences are lists and arrays
p27: often the term list refers either to true lists or to dotted lists.
When the distinction is important, the term "true list" will be
used to refer to a list terminated by nil. Most functions
advertised to operate on lists expect to be given true lists.
Throughout this manual, unless otherwise specified, it is an
error to pass a dotted list to a function that is specified
to require a list as an argument.
p27: implementors are encouraged to use the equivalent of the predicate
ENDP whenever it is necessary to test for the end of a list.
Whenever feasible, this test should explicitly signal an error
if a list is found to be terminated by a non-nil atom. However,
such an explicit error is not required ....
It seems that one should 'signal an error' and that it 'is an error'
but, well, maybe not.
comments? Has this been resolved before?
tim
DALY@IBM.COM
IBM T.J. Watson Research Center
Yorktown Heights, N.Y.
∂27-Aug-87 1344 Moon@STONY-BROOK.SCRC.Symbolics.COM The values returned by SETF
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Aug 87 13:44:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 222421; Thu 27-Aug-87 16:45:50 EDT
Date: Thu, 27 Aug 87 16:45 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: The values returned by SETF
To: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12329311876.BABYL@>
Message-ID: <870827164522.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 25 Aug 1987 10:12 EDT
From: Ram@C.CS.CMU.EDU
Date: Monday, 24 August 1987 14:47-EDT
From: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
To: D. Loewenstern <dml at NADC.ARPA>
Re: The values returned by SETF
Date: Mon, 24 Aug 87 14:25:04 EDT
From: dml@nadc.arpa (D. Loewenstern)
Is the value returned by SETF defined in general, for all
standard get/put functions?
Specifically, what is returned by (SETF (VALUES IGNORE X)
(VALUES 1 2))?
SETF returns the values of its last subform (CLtL p.97).
Actually, it says "the ultimate result of evaluating the setf form is
the value of newvalue." I would interpret your restatement to mean
that it has to return all the values of the newvalue form. I can't
see how you can do this in a Common Lisp macro without using
Multiple-Value-List. At least in our implementation:
(setf foo (values 1 2 3)) => 1
I would guess that the actual rule is that setf returns the number of
values that the setf method was expecting (supposing that the setf
method writer bothers to return the right value(s)).
The setf method writer has to return the right values, or he didn't write
his setf method correctly. The question is what are the right values.
I now agree with you that it shouldn't be all the values of <newvalue>,
and that CLtL isn't trying to say that.
Here's what I would propose. For all of the standard SETFs documented
in CLtL, which use only one value of <newvalue>, a portable program
can depend on SETF returning that one value and cannot depend on any
additional values. Implementations that implement the extension
(SETF (VALUES ...) ...) should return all the values that are used.
Thus the answer to the original question is that in implementations
where the form is not an error, it returns two values, 1 and 2.
∂28-Aug-87 0718 decvax!cvbnet!expert!pmorris@decwrl.dec.com New Reader
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 28 Aug 87 07:18:14 PDT
Received: from decvax.dec.com by decwrl.dec.com (5.54.4/4.7.34)
id AA09869; Fri, 28 Aug 87 07:18:26 PDT
Received: from admin.uucp (mcae) by cvbnet.uucp (2.0/SMI-2.0)
id AA02024; Fri, 28 Aug 87 10:04:34 edt
Received: from expert.uucp by admin.uucp (3.2/SMI-3.0DEV3)
id AA13811; Fri, 28 Aug 87 10:09:13 EDT
Received: by expert.uucp (3.2/SMI-3.0DEV3)
id AA04278; Fri, 28 Aug 87 10:00:48 EDT
Date: Fri, 28 Aug 87 10:00:48 EDT
From: decvax!cvbnet!expert!pmorris@decwrl.dec.com (Peter Morris )
Message-Id: <8708281400.AA04278@expert.uucp>
To: cvbnet!decvax!decwrl!sail.stanford.edu!common-lisp
Subject: New Reader
Please add me to the mail list for common-lisp.
Thank you.
...!decwrl!decvax!cvbnet!expert!pmorris
Peter J. Morris
Computervision Inc.
14 Crosby Drive
Bedford, MA 01730
(617) 275-1800 X4140
∂28-Aug-87 0849 sandra%orion@cs.utah.edu cleanup status?
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 87 08:49:18 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA01843; Fri, 28 Aug 87 09:52:13 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA15136; Fri, 28 Aug 87 09:52:09 MDT
Date: Fri, 28 Aug 87 09:52:09 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8708281552.AA15136@orion.utah.edu>
Subject: cleanup status?
To: common-lisp@sail.stanford.edu
Have there been any decisions made by the cleanup committee on issues that
have been previously hashed out in gory detail on this mailing list? If so,
is there a document that describes what changes have been approved? Some of
the areas of concern are:
- which DEFxxx forms should be processed at compile time
- clarifications on syntax for DEFMACRO lambda lists
- PARSE-BODY function and extensions to &BODY
- declarations in FLET/LABELS
- etc.
I don't want to initiate more flaming on these topics, I just want to know
if anything has been resolved or not.
-Sandra
-------
∂28-Aug-87 0916 edsel!bhopal!jonl@labrea.stanford.edu length
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 87 09:16:42 PDT
Received: by labrea.stanford.edu; Fri, 28 Aug 87 08:57:31 PDT
Received: from bhopal.edsel.com by edsel.uucp (3.2/SMI-2.0)
id AA06656; Fri, 28 Aug 87 09:05:08 PDT
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA00537; Fri, 28 Aug 87 09:05:15 PDT
Date: Fri, 28 Aug 87 09:05:15 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708281605.AA00537@bhopal.edsel.com>
To: labrea!DALY%ibm.com@labrea.stanford.edu
Cc: labrea!common-lisp%sail@labrea.stanford.edu
In-Reply-To: Timothy Daly's message of 27 August 1987, 14:14:28 EDT <082787.141428.daly@ibm.com>
Subject: length
In addition to your list of quotes from CLtL pertaining to (LENGTH '(3 . 3)),
I refer you to page 265, which says that "LIST-LENGTH could be implemented
as follows:
(defun list-length (x)
(do ((n 0 (+ 2 n))
(fast x (cddr fast))
(slow x (cdr slow)))
(nil)
(when (endp fast) (return n))
(when (endp (cdr fast)) (return (+ n 1)))
(when (and (eq fast slot) (> n 0)) (return nil))))
"
The use of 'endp' here seems to imply that Lucid's implemention is not
in conformance with CLtL. The decision to admit non-standard lists
everywhere in the sequence functions was taken long before my coming
to Lucid, and no one now seems to remember exactly why it was decided
that way. But I have heard claims that the matter was discussed with
Guy Steele in the fall of 1984, and he concurred (so goes the claim)
that signalling an error on non-standard lists isn't required.
-- JonL --
∂28-Aug-87 1246 KMP@STONY-BROOK.SCRC.Symbolics.COM length
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Aug 87 12:45:52 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223450; Fri 28-Aug-87 15:46:11 EDT
Date: Fri, 28 Aug 87 15:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: length
To: DALY@IBM.COM, edsel!bhopal!jonl@LABREA.STANFORD.EDU
cc: Common-Lisp@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <082787.141428.daly@ibm.com>,
<8708281605.AA00537@bhopal.edsel.com>
Message-ID: <870828154557.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 27 August 1987, 14:14:28 EDT
From: Timothy Daly <DALY@ibm.com>
Is (LENGTH '(3 . 3)) an error?
Yes, but it doesn't necessarily signal an error.
Lucid Common returns 1.
Symbolics Common returns error.
This is reasonable and consistent. You're talking about a situation
which is beyond the scope of the specification.
[By the way, as a point of terminology, programs don't "return" errors,
they signal them. Indeed, signalling an error is what one does when one
doesn't want to return.]
The bible states:
p248: length takes a sequence
p245: sequences are lists and arrays
p27: often the term list refers either to true lists or to dotted lists.
When the distinction is important, the term "true list" will be
used to refer to a list terminated by nil. Most functions
advertised to operate on lists expect to be given true lists.
Throughout this manual, unless otherwise specified, it is an
error to pass a dotted list to a function that is specified
to require a list as an argument.
p27: implementors are encouraged to use the equivalent of the predicate
ENDP whenever it is necessary to test for the end of a list.
Whenever feasible, this test should explicitly signal an error
if a list is found to be terminated by a non-nil atom. However,
such an explicit error is not required ....
It seems that one should 'signal an error' and that it 'is an error'
but, well, maybe not.
The wording you cite is extremely clear to me. The situation is an error.
Implementations are encouraged to signal an error (Symbolics does this)
but are not required to (Lucid does this).
comments? Has this been resolved before?
Probably -- though in fact there is nothing really to resolve. The point of
"is an error" situations is that we're telling programmers that they cannot
depend on the behavior of their programs in this situation. See the bottom
of p5 -- it is technically legitimate for (length '(3 . 3)) to do anything
at all.
-----
Date: Fri, 28 Aug 87 09:05:15 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
In addition to your list of quotes from CLtL pertaining to (LENGTH '(3 . 3)),
I refer you to page 265, which says that "LIST-LENGTH could be implemented
as follows:
(defun list-length (x)
(do ((n 0 (+ 2 n))
(fast x (cddr fast))
(slow x (cdr slow)))
(nil)
(when (endp fast) (return n))
(when (endp (cdr fast)) (return (+ n 1)))
(when (and (eq fast slot) (> n 0)) (return nil))))
"
The use of 'endp' here seems to imply that Lucid's implemention is not
in conformance with CLtL. The decision to admit non-standard lists
everywhere in the sequence functions was taken long before my coming
to Lucid, and no one now seems to remember exactly why it was decided
that way. But I have heard claims that the matter was discussed with
Guy Steele in the fall of 1984, and he concurred (so goes the claim)
that signalling an error on non-standard lists isn't required.
Don't sell your people short, Jonl. I think the current Lucid position is
completely defensible. (It happens not to be the behavior I'd prefer
personally, but my objections would be aesthetic, not biblical.) The use
of ENDP is what makes it optional whether you support dotted lists. The
description of ENDP on p264 quite clearly says it is "false for conses,
true for NIL, and an error for all other arguments." p5 defines what
"is an error" means and it's quite liberal in what interpretations it
allows. Now, the implementation note which follows suggests that if it is
not going to signal an error, it should return T for non-null atoms
(which Lucid presumably does), but I'm not completely convinced that even
that behavior is forced (because of its placement in a note rather than
in the text of the definition and because the text of the definition is so
unambiguous).
∂28-Aug-87 1645 edsel!bhopal!jonl@labrea.stanford.edu length
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 87 16:45:06 PDT
Received: by labrea.stanford.edu; Fri, 28 Aug 87 16:25:52 PDT
Received: from bhopal.edsel.com by edsel.uucp (3.2/SMI-2.0)
id AA07586; Fri, 28 Aug 87 15:19:51 PDT
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA02711; Fri, 28 Aug 87 15:20:00 PDT
Date: Fri, 28 Aug 87 15:20:00 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708282220.AA02711@bhopal.edsel.com>
To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Cc: labrea!DALY%IBM.COM@labrea.stanford.edu,
labrea!Common-Lisp%SAIL@labrea.stanford.edu
In-Reply-To: Kent M Pitman's message of Fri, 28 Aug 87 15:45 EDT <870828154557.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: length
Your presumption that Lucid's ENDP returns something rather than
signalling an error on "erroneous" arguments isn't borne out.
The intended point about CLtL, p265, is that LIST-LENGTH should view
the matter the same way that ENDP does.
-- JonL --
∂28-Aug-87 1702 KMP@STONY-BROOK.SCRC.Symbolics.COM length
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Aug 87 17:02:17 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223700; Fri 28-Aug-87 20:02:37 EDT
Date: Fri, 28 Aug 87 20:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: length
To: edsel!bhopal!jonl@LABREA.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, DALY@IBM.COM,
Common-Lisp@SAIL.STANFORD.EDU
In-Reply-To: <8708282220.AA02711@bhopal.edsel.com>
Message-ID: <870828200231.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 28 Aug 87 15:20:00 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Your presumption that Lucid's ENDP returns something rather than
signalling an error on "erroneous" arguments isn't borne out.
Sorry. I must have mis-read something. In any case, my main point was
that much flexibility is (for better or worse) legal. I thought you
were flexing differently than we, but even if you weren't, some other
implementation probably is.
The intended point about CLtL, p265, is that LIST-LENGTH should view
the matter the same way that ENDP does.
[Assuming I understand you this time,] I don't agree. It is permitted
to do so, but not required to do so. The definition shown is only a
sample and is not definitional. Just because they both do something
undefined doesn't mean they have to do the same undefined thing.
My reading is that an implementation for which (ENDP 'A) returns T may
still signal an error on (LIST-LENGTH '(A . A)). Similarly, even if
(LIST-LENGTH '(A . A)) returns 1, (ENDP 'A) may signal an error.
It is somewhat possible that what you say (LIST-LENGTH and ENDP should
behave in a correlated fashion) was the intention of the author(s), but
if so I don't believe that this intent was adequately carried through
into the written word.
∂29-Aug-87 1618 Masinter.pa@Xerox.COM Re: cleanup status?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Aug 87 16:17:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 AUG 87 16:18:10 PDT
Date: 29 Aug 87 16:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: cleanup status?
In-reply-to: sandra%orion%cs.utah:EDU:Xerox's message of 28 Aug 87 09:19
To: common-lisp@Sail.stanford.edu
Message-ID: <870829-161810-4731@Xerox>
A number of messages have come by referring to the "cleanup committee".
The cleanup committee is a sub-committee of X3J13, which, as you know,
is the ANSII organization working on Common Lisp standardization.
Our process has been to solicit proposals from members of X3J13 (and
ourselves), and then make recommendations to X3J13. All decisions about
the standard must be made by the full X3J13 committee. Results of those
ballots are reported in the X3J13 minutes.
While a number of us read Common-lisp@Sail.stanford.edu, and we
frequently use it as a resource, there is no process by which issues
discussed on this list automatically become proposals for X3J13.
Of the issues you mention, none of them have been brought up before the
cleanup committee directly.
I believe two of the issues you mention ("which DEFxxx forms should be
processed at compile time", and "declarations in FLET/LABELS") await
some further input from other subcommittees.
∂03-Sep-87 2119 GINN@sumex-aim.stanford.edu Common Lisp LOOP
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 87 21:19:20 PDT
Received: from SUMEX-AIM.Stanford.EDU by navajo.stanford.edu with TCP; Thu, 3 Sep 87 21:16:22 PDT
Date: Thu, 3 Sep 87 21:19:52 PDT
From: Michael Ginn <GINN@sumex-aim.stanford.edu>
Subject: Common Lisp LOOP
To: common-lisp%sail.stanford.edu@navajo.stanford.edu
Message-Id: <12331825355.20.GINN@SUMEX-AIM.STANFORD.EDU>
Has anyone written a LOOP macro for common lisp? Most of the common
lisps I use, besides the Symbolics and TI versions, have no definition at all
for LOOP. (In Steele's book, LOOP is mentioned only as a future possibility
for extension of the common lisp specification).
Most specifically, I'd like to use it in KCL and in Post-Penultimate
Common Lisp, but of course any definition conforming to the specification
would probably work.
---Michael Ginn
-------
∂04-Sep-87 1052 Moon@STONY-BROOK.SCRC.Symbolics.COM Common Lisp LOOP
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Sep 87 10:52:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 228277; Fri 4-Sep-87 13:53:08 EDT
Date: Fri, 4 Sep 87 13:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Common Lisp LOOP
To: Michael Ginn <GINN@sumex-aim.stanford.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <12331825355.20.GINN@SUMEX-AIM.STANFORD.EDU>
File-References: AI.AI.MIT.EDU: GSB; CLLOOP >
Message-ID: <870904135252.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 3 Sep 87 21:19:52 PDT
From: Michael Ginn <GINN@sumex-aim.stanford.edu>
Has anyone written a LOOP macro for common lisp?
Check the file GSB;CLLOOP which you can retrieve from AI.AI.MIT.EDU
by FTP. You don't need a password to retrieve files from there.
∂05-Sep-87 1031 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Re: Common Lisp LOOP
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Sep 87 10:31:14 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa04506; 5 Sep 87 10:06 EDT
Received: from utokyo-relay by RELAY.CS.NET id ac11318; 5 Sep 87 9:48 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA13118; Sat, 5 Sep 87 22:41:23 JST
Received: by titcca.cc.titech.junet (4.12/6.2Junet)
id AA18600; Sat, 5 Sep 87 22:09:13 jst
Received: by nttlab.NTT (4.12/6.2NTT.g) with TCP; Sat, 5 Sep 87 19:51:20 jst
Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet)
id AA03223; Sat, 5 Sep 87 12:57:38 jst
Received: by kurims.kurims.kyoto-u.junet (3.2/6.2Junet)
id AA00683; Sat, 5 Sep 87 11:45:42 JST
Date: Sat, 5 Sep 87 11:45:42 JST
From: Taiichi Yuasa <yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <yuasa@kurims.kurims.kyoto-u.junet>
Message-Id: <8709050245.AA00683@kurims.kurims.kyoto-u.junet>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Re: Common Lisp LOOP
Here is my code for LOOP, which will be included in the next release of
KCL available from University of Texas.
-- Taiichi
------------------- Cut Here ----------------------
;; (c) Copyright Taiichi Yuasa and Masami Hagiya, 1984. All rights reserved.
;; Copying of this file is authorized to users who have executed the true and
;; proper "License Agreement for Kyoto Common LISP" with SIGLISP.
;;;; loop.lsp
;;;;
;;;; defines the sophisticated LOOP macro, with the hope it's
;;;; compatible with Symbolics Common Lisp.
(in-package 'lisp)
(export '(define-loop-path define-loop-sequence-path))
(in-package 'system)
(export '(loop-tequal loop-tmember loop-tassoc loop-named-variable))
(eval-when (compile) (proclaim '(optimize (safety 2) (space 3))))
(defvar *loop-named-variables* nil)
(defun loop-tequal (x key) "
Args: (object symbol)
Returns T if OBJECT is a symbol with the same print name as SYMBOL; NIL
otherwise. Used typically to define a loop-path."
(and (symbolp x)
(or (eq x key)
(string= (symbol-name x) (symbol-name key)))))
(defun loop-tmember (x keys) "
Args: (object symbols)
Similar to MEMBER but uses SI:LOOP-TEQUAL to compare OBJECT and each element
of SYMBOLS. Used typically to define a loop-path."
(and (symbolp x)
(member (symbol-name x) keys :test #'string= :key #'symbol-name)))
(defun loop-tassoc (x alist) "
Args: (object alist)
Similar to ASSOC but uses SI:LOOP-TEQUAL to compare OBJECT and the car of each
element of ALIST using . Used typically to define a loop-path."
(and (symbolp x)
(assoc (symbol-name x) alist
:test #'(lambda (s key) (string= s (symbol-name key))))))
(defun loop-named-variable (key) "
Args: (symbol)
Returns the name of the variable for SYMBOL, which is specified by the USING
key of LOOP. Returns NIL if no variable is specified. Should be used only in
loop-path definitions."
(cadr (loop-tassoc key *loop-named-variables*)))
(defmacro test body `(macroexpand-1 '(loop ,@body)))
(defvar *loop-paths* (make-hash-table :test 'equal))
(defmacro define-loop-path (name fun keys &rest data) "
Syntax: (define-loop-path name-or-names symbol keys &rest data)
Defines loop-paths. When LOOP encounters a clause of the form
FOR var [type] BEING {THE | EACH} name (key1 thing1)...(keyn thingn)
LOOP invokes the function named SYMBOL with the following arguments.
1. name
2. var
3. type (or NIL if type is not specified)
4. ((key1 thing1)...(keyn thingn))
5. NIL
6. keys specified by DEFINE-LOOP-PATH
7. data specified by DEFINE-LOOP-PATH
In case of
FOR var [type] BEING form AND ITS name (key1 thing1)...(keyn thingn)
LOOP invokes the same function with the same arguments except for the fourth
and fifth:
4. ((OF form) (key1 thing1)...(keyn thingn))
5. T
Then LOOP expects a list of six or ten elements returned by the function
1. variable bindings as a list ((var init)...(var init))
2. prologue forms as a list (form...form)
3-6. general iteration spec
7-10. first iteration spec
For a six-element list, 7-10 are assumed the same as 3-6, respectively. The
iteration spec is
3. pre-step endtest
4. steps as a list ((var form)...(var form))
5. post-step endtest
6. pseudo-steps as a list ((var form)...(var form))"
`(progn ,.(mapcar #'(lambda (x)
`(setf (gethash ,(symbol-name x) *loop-paths*)
(list ',fun ',keys ',data)))
(if (symbolp name) (list name) name))
',name))
(defmacro define-loop-sequence-path (name fetch size &optional type1 type2) "
Syntax: (define-loop-sequence-path name-or-names fetch-fun size-fun
&optional type1 type2)
Defines loop-sequence-paths."
(declare (ignore type1 type2))
`(progn ,.(mapcar #'(lambda (x)
`(setf (gethash ,(symbol-name x) *loop-paths*)
(list nil ',fetch ',size)))
(if (symbolp name) (list name) name))
',name))
(defvar *loop-body*)
(defvar *bindings*)
(defvar *prologue*)
(defvar *pre-steps*)
(defvar *body*)
(defvar *post-steps*)
(defvar *epilogue*)
(defvar *acc*)
(defvar *acclist*)
(defvar *named-block*)
(defvar *t2*)
(defvar *it*)
(defvar *its-name*)
(defvar *it-is-used*)
(defvar *temps*)
(defvar *aux-bindings*)
(defmacro lkcase clauses
(let ((key (gensym))
(form nil))
(dolist (clause (reverse clauses)
`(let ((,key (if (symbolp (car *loop-body*))
(symbol-name (car *loop-body*)) "")))
,form))
(declare (object clause))
(setq form
(if (eq (car clause) :ow)
`(progn ,@(cdr clause))
`(if ,(cond ((atom (car clause))
`(string= ,key ,(symbol-name (car clause))))
(t `(or ,.(mapcar
#'(lambda (x)
`(string= ,key ,(symbol-name x)))
(car clause)))))
(progn (pop-body) ,@(cdr clause))
,form))))))
(defmacro pop-body () '(pop *loop-body*))
(defmacro peek-body () '(car *loop-body*))
(defmacro end-body () '(endp *loop-body*))
(defmacro do-it (form) `(push ,form *body*))
(defconstant *default-terminators*
'(REPEAT FOR AS WITH NODECLARE INITIALLY FINALLY DO DOING COLLECT COLLECTING
NCONC NCONCING APPEND APPENDING COUNT COUNTING SUM SUMMING MAXIMIZE
MINIMIZE WHILE UNTIL LOOP-FINISH ALWAYS NEVER THEREIS WHEN IF UNLESS NAMED
RETURN))
(defun parse-type (terminators)
(cond ((end-body) t)
((loop-tmember (peek-body) terminators) t)
(t (pop-body))))
(defmacro aux-bind (v init) `(push (list ,v ,init) *aux-bindings*))
(defun get-it ()
(unless *it* (error "The IT keyword comes in a wrong place."))
(setq *it-is-used* t)
(or *its-name*
(prog1 (setq *its-name* (gensym))
(aux-bind *its-name* nil))))
(defmacro loop *loop-body* "
Syntax: (loop {list-form}* {clause}*)
Upper compatible extension of the Common Lisp LOOP macro. If no CLAUSE is
given, then LOOP simply repeats execution of LIST-FORMs. The use of CLAUSEs
is expected to be compatible with those in Symbolics Common Lisp, with the
following syntax.
clause ::=
REPEAT form [AND more-iteration-clauses]
| {FOR | AS} FOR-clause [AND more-iteration-clauses]
| WITH var [type] [= form]
| {INITIALLY | FINALLY} form {list-form}*
| {DO | DOING} form {list-form}*
| {WHEN | IF | UNLESS} form clause {AND clause}* [ELSE clause {AND clause}*]
| {COLLECT | NCONC | APPEND} {form | IT} [INTO symbol]
| {COUNT | SUM} {form | IT} [INTO symbol] [type]
| {MAXIMIZE | MINIMIZE} {form | IT} [type] [INTO symbol]
| {WHILE | UNTIL | ALWAYS | NEVER | THEREIS} form
| LOOP-FINISH
| NAMED symbol
| NODECLARE symbol-list
| RETURN {form | IT}
FOR-clause ::=
var [type] { FROM form { {TO | DOWNTO | BELOW | ABOVE | BY} form }*
| {DOWNFROM | UPFROM} form [BY form]
| {IN | ON} form [BY form]
| = form [THEN form]
| FIRST form THEN form
| BEING form AND {ITS | EACH} loop-path {key thing}*
| BEING [THE | EACH] loop-path {key thing}*
}
Type declarations are simply ignored in the current version. The only known
differences from Symbolics Common Lisp LOOP are:
1. DEFAULT-LOOP-PATH is not supported simply because I (Taiichi) do
not know in which case I should use the default.
2. No built-in loop-path is defined. In order to define a loop-path,
use DEFINE-LOOP-PATH or DEFINE-LOOP-SEQUENCE-PATH.
See SI:LOOP-TEQUAL, SI:LOOP-TMEMBER, SI:LOOP-TASSOC, and SI:LOOP-NAMED-
VARIABLES."
(let (*bindings* *temps* *aux-bindings*
*prologue* *pre-steps* *body* *post-steps* *epilogue*
*acc* *acclist* *named-block* (*t2* (gensym))
*it* *its-name* *it-is-used*)
(parse-loop-body)
(let* ((identical-steps
(do ((x nil))
((or (endp *pre-steps*)
(endp *post-steps*)
(not (equal (car *pre-steps*) (car *post-steps*))))
x)
(push (pop *pre-steps*) x)
(pop *post-steps*)))
(t1 (gensym))
(template (list 'tagbody))
(form `(block ,*named-block*
,(lv-bind *bindings* *aux-bindings* template))))
(setf (cdr template)
`(,.(nreverse *prologue*)
,.(nreverse
(mapcar #'(lambda (x)
(if (eq (car x) 'when) x (lv-set x)))
*pre-steps*))
,t1
,.(mapcar #'(lambda (x)
(if (eq (car x) 'when) x (lv-set x)))
identical-steps)
,.(nreverse *body*)
,.(nreverse
(mapcar #'(lambda (x)
(if (eq (car x) 'when) x (lv-set x)))
*post-steps*))
(go ,t1)
,*t2*
,.(nreverse *epilogue*)
(return ,*acc*)))
form)))
(defun lv-bind (bindings aux-bindings form)
(let ((sb nil) (pb nil))
(labels ((lv-bind-tree (tree form)
(cond ((null tree))
((atom tree) (push (list tree form) sb))
(t (lv-bind-tree (cdr tree) `(cdr ,form))
(lv-bind-tree (car tree) `(car ,form)))))
(lv-bind-nil (tree)
(cond ((null tree))
((atom tree) (push tree sb))
(t (lv-bind-nil (cdr tree))
(lv-bind-nil (car tree))))))
(dolist (b aux-bindings) (push b sb))
(dolist (bs bindings)
(cond ((endp (cdr bs))
(let ((b (car bs)))
(cond ((or (symbolp b) (symbolp (car b))) (push b sb))
((null (cadr b)) (lv-bind-nil (car b)))
(t (let ((temp (gensym)))
(lv-bind-tree (car b) temp)
(push (list temp (cadr b)) sb)
(push temp *temps*))))))
(t (dolist (b (reverse bs))
(cond ((or (symbolp b) (symbolp (car b))) (push b pb))
((null (cadr b)) (lv-bind-nil (car b)))
(t (let ((temp (gensym)))
(lv-bind-tree (car b) temp)
(push (list temp (cadr b)) pb)
(push temp *temps*)))))
(when sb (setq form `(let* ,sb ,form)) (setq sb nil))
(when pb (setq form `(let ,pb ,form)) (setq pb nil)))))
(if sb `(let* ,sb ,form) form))))
(defun lv-set (sl)
(let ((more-temps nil) (temps *temps*) (ps nil) (ss nil))
(labels ((lv-set-tree (tree form)
(cond ((null tree))
((atom tree) (push form ss) (push tree ss))
(t (lv-set-tree (cdr tree) `(cdr ,form))
(lv-set-tree (car tree) `(car ,form))))))
(cond ((endp (cdr sl))
(let ((s (car sl)))
(cond ((symbolp (car s)) `(setq ,(car s) ,(cadr s)))
((endp temps)
(let ((temp (gensym)))
(lv-set-tree (car s) temp)
`(let ((,temp ,(cadr s))) (setq ,@ss))))
(t (let ((temp (car temps)))
(lv-set-tree (car s) temp)
`(setq ,temp ,(cadr s) ,@ss))))))
(t (dolist (s (reverse sl))
(cond ((symbolp (car s))
(push (cadr s) ps)
(push (car s) ps))
(t (let (temp)
(cond (temps (setq temp (pop temps)))
(t (setq temp (gensym))
(push temp more-temps)))
(push (cadr s) ps) (push temp ps)
(lv-set-tree (car s) temp)))))
(let ((body (if ss `((setq ,@ss)) nil)))
(when ps (push `(psetq ,@ps) body))
(cond (more-temps `(let* ,more-temps ,@body))
((endp (cdr body)) (car body))
(t (cons 'progn body)))))))))
(defun lv-pair-tree (tree form &optional (rest nil))
(cond ((null tree) rest)
((atom tree) (cons (list tree form) rest))
(t (lv-pair-tree (car tree) `(car ,form)
(lv-pair-tree (cdr tree) `(cdr ,form) rest)))))
(defun lv-tree-symbols (tree &optional (more nil))
(cond ((null tree) more)
((atom tree) (cons tree more))
(t (lv-tree-symbols (car tree) (lv-tree-symbols (cdr tree) more)))))
(defun parse-loop-body ()
(when (and (not (end-body))
(not (symbolp (car *loop-body*))))
(parse-do))
(do () ((end-body)) (parse-a-clause)))
(defun parse-a-clause ()
(lkcase
((REPEAT) (do ((inf (parse-repeat)
(merge-inf inf (lkcase (REPEAT (parse-repeat))
((FOR AS) (parse-for))
(WITH (parse-with))
(:ow (parse-repeat))))))
((lkcase (AND nil) (:ow t))
(set-iteration inf))))
((FOR AS) (do ((inf (parse-for)
(merge-inf inf (lkcase (REPEAT (parse-repeat))
((FOR AS) (parse-for))
(WITH (parse-with))
(:ow (parse-for))))))
((lkcase (AND nil) (:ow t))
(set-iteration inf))))
((WITH) (do ((inf (parse-with)
(merge-inf inf (lkcase (REPEAT (parse-repeat))
((FOR AS) (parse-for))
(WITH (parse-with))
(:ow (parse-with))))))
((lkcase (AND nil) (:ow t))
(set-iteration inf))))
((NODECLARE) (pop-body))
((INITIALLY) (parse-initially))
((FINALLY) (parse-finally))
((DO DOING) (parse-do))
((COLLECT COLLECTING) (parse-collect))
((NCONC NCONCING) (parse-nconc))
((APPEND APPENDING) (parse-append))
((COUNT COUNTING) (parse-count))
((SUM SUMMING) (parse-sum))
((MAXIMIZE MAXIMIZING) (parse-maximize))
((MINIMIZE MINIMIZING) (parse-minimize))
((WHILE) (do-it `(unless ,(pop-body) (go ,*t2*))))
((UNTIL) (do-it `(when ,(pop-body) (go ,*t2*))))
((LOOP-FINISH) (do-it `(go ,*t2*)))
((ALWAYS) (do-it `(unless ,(pop-body) (return))))
((NEVER) (do-it `(when ,(pop-body) (return))))
((THEREIS) (parse-thereis))
((WHEN IF) (parse-when t))
((UNLESS) (parse-when nil))
((NAMED) (setq *named-block* (pop-body)))
((RETURN) (do-it `(return ,(lkcase (IT (get-it)) (:ow (pop-body))))))
(:ow (error "~S is an illegal LOOP keyword." (car *loop-body*)))))
(defun merge-inf (inf inf1) (mapcar #'append inf inf1))
(defun set-iteration (inf)
(flet ((make-end-test (tests)
(cond ((cdr tests) `(when (or ,@tests) (go ,*t2*)))
(t `(when ,(car tests) (go ,*t2*))))))
(push (first inf) *bindings*)
(mapcar #'(lambda (x) (push x *prologue*)) (second inf))
(when (third inf) (push (make-end-test (third inf)) *post-steps*))
(when (fourth inf) (push (fourth inf) *post-steps*))
(when (fifth inf) (push (make-end-test (fifth inf)) *post-steps*))
(when (sixth inf) (push (sixth inf) *post-steps*))
(when (seventh inf) (push (make-end-test (seventh inf)) *pre-steps*))
(when (eighth inf) (push (eighth inf) *pre-steps*))
(when (ninth inf) (push (make-end-test (ninth inf)) *pre-steps*))
(when (tenth inf) (push (tenth inf) *pre-steps*))))
(defun parse-repeat ()
(let ((temp (gensym)))
(list `((,temp ,(pop-body))) nil
`((not (plusp ,temp))) `((,temp (1- ,temp))) nil nil
`((not (plusp ,temp))) `((,temp (1- ,temp))) nil nil)))
(defun parse-for ()
(let ((v (pop-body)))
(parse-type '(FROM DOWNFROM UPFROM IN ON = FIRST BEING))
(lkcase
(FROM (let ((init (pop-body)) test limit (step-fun '+) (step 1))
(lkcase
(TO (setq test '> limit (pop-body))
(lkcase (BY (setq step (pop-body)))))
(DOWNTO (setq test '< limit (pop-body) step-fun '-)
(lkcase (BY (setq step (pop-body)))))
(BELOW (setq test '>= limit (pop-body))
(lkcase (BY (setq step (pop-body)))))
(ABOVE (setq test '<= limit (pop-body) step-fun '-)
(lkcase (BY (setq step (pop-body)))))
(BY (setq step (pop-body))
(lkcase
(TO (setq test '> limit (pop-body)))
(DOWNTO (setq test '< limit (pop-body) step-fun '-))
(BELOW (setq test '>= limit (pop-body)))
(ABOVE (setq test '<= limit (pop-body) step-fun '-)))))
(parse-for1 v init test limit step-fun step)))
(DOWNFROM
(parse-for1 v (pop-body) nil nil '- (lkcase (BY (pop-body)) (:ow 1))))
(UPFROM
(parse-for1 v (pop-body) nil nil '+ (lkcase (BY (pop-body)) (:ow 1))))
(IN (let* ((form (pop-body))
(fun (lkcase (BY (pop-body)) (:ow '#'cdr)))
(temp (gensym))
(inf (list nil nil
nil nil `((endp ,temp)) nil
nil nil `((endp ,temp)) nil)))
(cond ((and (consp fun) (eq (car fun) 'function))
(push `(,temp (,(cadr fun) ,temp)) (fourth inf)))
((constantp fun)
(push `(,temp (funcall ,fun ,temp)) (fourth inf)))
(t (let ((temp1 (gensym)))
(push (list temp1 fun) (first inf))
(push `(,temp (funcall ,temp1 ,temp)) (fourth inf)))))
(push (list temp form) (first inf))
(cond ((symbolp v)
(push `(,v (car ,temp)) (sixth inf))
(push `(,v (car ,temp)) (tenth inf))
(push v (first inf)))
(t (let ((pairs (lv-pair-tree v `(car ,temp))))
(setf (sixth inf) pairs)
(setf (tenth inf) pairs))
(mapc #'(lambda (x) (push x (first inf)))
(nreverse (lv-tree-symbols v)))))
inf))
(ON (let* ((form (pop-body))
(fun (lkcase (BY (pop-body)) (:ow '#'cdr))))
(cond ((symbolp v)
(let ((inf (list nil nil
nil nil `((endp ,v)) nil
nil nil `((endp ,v)) nil)))
(cond ((and (consp fun) (eq (car fun) 'function))
(push `(,v (,(cadr fun) ,v)) (fourth inf)))
(t (unless (constantp fun)
(let ((temp1 (gensym)))
(push (list temp1 fun) (first inf))
(setq fun temp1)))
(push `(,v (funcall ,fun ,v)) (fourth inf))))
(push (list v form) (first inf))
inf))
(t (let* ((temp (gensym))
(pairs (lv-pair-tree v temp))
(inf (list nil nil
nil nil `((endp ,temp)) pairs
nil nil `((endp ,temp)) pairs)))
(cond ((and (consp fun) (eq (car fun) 'function))
(push `(,temp (,(cadr fun) ,temp))
(fourth inf)))
(t (unless (constantp fun)
(let ((temp1 (gensym)))
(push (list temp1 fun) (first inf))
(setq fun temp1)))
(push `(,temp (funcall ,fun ,temp))
(fourth inf))))
(push (list temp form) (first inf))
(mapc #'(lambda (x) (push x (first inf)))
(nreverse (lv-tree-symbols v)))
inf)))))
(= (let* ((init (pop-body)))
(lkcase (THEN (list `((,v ,init)) nil
nil `((,v ,(pop-body))) nil nil
nil nil nil nil))
(:ow (list `((,v nil)) nil
nil `((,v ,init)) nil nil
nil `((,v ,init)) nil nil)))))
(FIRST (let* ((init (pop-body))
(form (lkcase (THEN (pop-body))
(:ow (error "THEN missing after FIRST.")))))
(list `((,v nil)) nil
nil `((,v ,form)) nil nil
nil `((,v ,init)) nil nil)))
(BEING (parse-loop-path v))
(:ow (error "~S is an illegal LOOP keyword" (car *loop-body*))))))
(defun parse-for1 (v init test limit step-fun step)
(unless (symbolp v)
(error "The FOR control variable ~S cannot be destructured." v))
(let ((inf (make-list 10)))
(unless (numberp step)
(let ((temp (gensym)))
(push (list temp step) (first inf))
(setq step temp)))
(when test
(unless (numberp limit)
(let ((temp (gensym)))
(push (list temp limit) (first inf))
(setq limit temp)))
(let ((x (list test v limit)))
(push x (fifth inf))
(push x (ninth inf))))
(push (list v init) (first inf))
(push (list v (list step-fun v step)) (fourth inf))
inf))
(defun parse-loop-path (v)
(let ((flag nil) (pps nil) path (*loop-named-variables* nil))
(lkcase
((EACH THE) (setq path (pop-body)))
(:ow (setq path (pop-body))
(lkcase
(AND (setq flag t)
(push (list 'of (pop-body)) pps)
(lkcase
((ITS EACH HIS HER THEIR)
(setq path (pop-body)))
(:ow (error "ITS is missing after FOR..BEING..AND.")))))))
(unless (symbolp path)
(error "The LOOP path-name ~S is not a symbol." path))
(let ((def (gethash (symbol-name path) *loop-paths*)))
∂07-Sep-87 0829 LINNDR%VUENGVAX.BITNET@forsythe.stanford.edu KCL LOOP posting
Received: from LINDY.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Sep 87 08:29:06 PDT
Received: by lindy.stanford.edu; Mon, 7 Sep 87 08:29:23 PDT
Received: by Forsythe.Stanford.EDU; Mon, 7 Sep 87 08:28:05 PDT
Date: Mon, 7 Sep 87 10:29 CDT
From: <LINNDR%VUENGVAX.BITNET@forsythe.stanford.edu> (David Linn)
Subject: KCL LOOP posting
To: common-lisp@sail.stanford.edu
X-Original-To: common-lisp@sail.stanford.edu, LINNDR
The LOOP posting by Taiichi Yuasa for KCL arrived here truncated. Did
this happen everywhere? If not, can someone arrange to send it to me
(please send mail first so that I don't receive multiple copies)?
David Linn
LINNDR@VUENGVAX.BITNET
...!seismo!uunet!vuse!drl
∂07-Sep-87 1014 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK KCL LOOP posting
Received: from TUNNEL.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 7 Sep 87 10:13:57 PDT
Received: from aiva.edinburgh.ac.uk by nss.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08808; 7 Sep 87 17:29 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Mon, 7 Sep 87 17:30:59 -0100
Message-Id: <12061.8709071630@aiva.ed.ac.uk>
To: common-lisp@sail.stanford.edu
Subject: KCL LOOP posting
> The LOOP posting by Taiichi Yuasa for KCL arrived here truncated.
Same here. Nor can I FTP it from anywhere, were someone to put it
somewhere.
-- Jeff (J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk)
∂09-Sep-87 0803 DALY@IBM.COM setf order of evaluation
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 87 08:03:05 PDT
Date: 9 September 1987, 10:31:51 EDT
From: Timothy Daly <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <090987.103153.daly@ibm.com>
Subject: setf order of evaluation
Given
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
what is the value of R and S?
Note that P97 of CLtL states that SETF guarantees the
left-to-right order of evaluation of its arguments.
(yes, i know it is crufty to change R).
Both Symbolics and Lucid seem to generate
R = (B 8) and S = (A 1 B 2 C 3)
which implies that the second argument of setf
is evaluated first. What did I miss?
tim
DALY@IBM.COM
IBM T.J. Watson Research Center
Yorktown Heights, N.Y. 10598
∂09-Sep-87 1139 Moon@STONY-BROOK.SCRC.Symbolics.COM setf order of evaluation
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Sep 87 11:39:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 230463; Wed 9-Sep-87 14:40:44 EDT
Date: Wed, 9 Sep 87 14:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: setf order of evaluation
To: Timothy Daly <DALY@ibm.com>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <090987.103153.daly@ibm.com>
Message-ID: <870909144023.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 9 September 1987, 10:31:51 EDT
From: Timothy Daly <DALY@ibm.com>
Given
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
what is the value of R and S?
Note that P97 of CLtL states that SETF guarantees the
left-to-right order of evaluation of its arguments.
(yes, i know it is crufty to change R).
Both Symbolics and Lucid seem to generate
R = (B 8) and S = (A 1 B 2 C 3)
which implies that the second argument of setf
is evaluated first. What did I miss?
It's not a good idea to speak of "arguments" when dealing with
forms that aren't function calls. It's less confusing to speak
of subforms. The subforms of that setf that get evaluated are
r
'b
(progn (setq r nil) 6)
so I think the behavior you describe is a bug (although the description
in CLtL is so ambiguous that the implementors of the respective systems
could easily disagree with me.)
I didn't look inside the Lucid implementation, but in the Symbolics
implementation the source of the bug is that (get-setf-method 'r)
returns NIL, NIL, (#:G6411), (SETQ R #:G6411), R, whereas it should
return (#:G6410), (R), (#:G6411), (SETQ R #:G6411), #:G6410. See
CLtL page 104 for the description of the meaning of these values.
Changing it to return the latter makes your SETF example behave as you
expected, evaluating R -before- bashing it, and setq'ing it to the updated
property list -after- setq'ing it to nil.
∂10-Sep-87 0741 NGALL@G.BBN.COM Re: setf order of evaluation
Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 10 Sep 87 07:41:40 PDT
Date: 10 Sep 1987 10:40-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: setf order of evaluation
From: NGALL@G.BBN.COM
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: DALY@IBM.COM, common-lisp@SAIL.STANFORD.EDU
Message-ID: <[G.BBN.COM]10-Sep-87 10:40:24.NGALL>
In-Reply-To: <870909144023.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 9 Sep 87 14:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: 9 September 1987, 10:31:51 EDT
From: Timothy Daly <DALY@ibm.com>
Given
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
what is the value of R and S?
...
Both Symbolics and Lucid seem to generate
R = (B 8) and S = (A 1 B 2 C 3)
...
so I think the behavior you describe is a bug (although the description
in CLtL is so ambiguous that the implementors of the respective systems
could easily disagree with me.)
I agree that it is a bug. Cf pg 99: "As an example of these semantic
rules, in the generalized-variable reference (SETF reference value)
the VALUE form must be evaluated AFTER all the subforms of the
reference because the value form appears to the right of them"
I didn't look inside the Lucid implementation, but in the Symbolics
implementation the source of the bug is that (get-setf-method 'r)
returns NIL, NIL, (#:G6411), (SETQ R #:G6411), R, whereas it should
return (#:G6410), (R), (#:G6411), (SETQ R #:G6411), #:G6410. See
CLtL page 104 for the description of the meaning of these values.
Changing it to return the latter makes your SETF example behave as you
expected, evaluating R -before- bashing it, and setq'ing it to the updated
property list -after- setq'ing it to nil.
Unfortunately, on pg 105 the setf method for the variable X is defined
to be () () (#:g0001) (setq X #:g0001) X. So if this is the right
place to fix things, then CLtL must be fixed too. This is fine with
me, but it would make SETF methods less efficient (or require them to
be more intelligent about optimizing).
-- Nick
∂10-Sep-87 1824 raible@orville.nas.nasa.gov Re: Common Lisp LOOP
Received: from ORVILLE.ARPA by SAIL.STANFORD.EDU with TCP; 10 Sep 87 18:24:02 PDT
Received: Thu, 10 Sep 87 18:24:00 PDT by orville.arpa (5.54/1.2)
Message-Id: <8709110124.AA20824@orville.arpa>
To: common-lisp@SAIL.STANFORD.EDU
Cc: raible@orville.nas.nasa.gov
Subject: Re: Common Lisp LOOP
Date: 10 Sep 87 18:23:58 PDT (Thu)
From: raible@orville.nas.nasa.gov
Well, I was hoping that it would get reposted since I received a
truncated copy of the KCL LOOP code.
Is there anyone who got the whole thing who would be willing to
repost, or send it to me?
Thanks - Eric Raible (raible@orville.nas.nasa.gov)
∂10-Sep-87 1919 franz!ficl!drb@ucbarpa.Berkeley.EDU setf order of evaluation
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 10 Sep 87 19:19:50 PDT
Received: by ucbarpa.Berkeley.EDU (5.58/1.25)
id AA20402; Thu, 10 Sep 87 19:20:51 PDT
Received: from ficl by franz (5.5/3.14)
id AA00482; Thu, 10 Sep 87 18:29:10 PDT
Received: by ficl (5.5/3.14)
id AA02338; Wed, 9 Sep 87 14:39:55 PDT
Date: Wed, 9 Sep 87 14:39:55 PDT
From: franz!ficl!drb@ucbarpa.Berkeley.EDU (David Barton)
Return-Path: <drb>
Message-Id: <8709092139.AA02338@ficl>
To: Moon@stony-brook.scrc.symbolics.com
Cc: DALY@ibm.com, common-lisp@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 9 Sep 87 14:40 EDT <870909144023.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: setf order of evaluation
Date: Wed, 9 Sep 87 14:40 EDT
From: David A. Moon <franz!STONY-BROOK.SCRC.Symbolics.COM!Moon>
Date: 9 September 1987, 10:31:51 EDT
From: Timothy Daly <DALY@ibm.com>
Given
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
what is the value of R and S?
Note that P97 of CLtL states that SETF guarantees the
left-to-right order of evaluation of its arguments.
(yes, i know it is crufty to change R).
Both Symbolics and Lucid seem to generate
R = (B 8) and S = (A 1 B 2 C 3)
which implies that the second argument of setf
is evaluated first. What did I miss?
It's not a good idea to speak of "arguments" when dealing with
forms that aren't function calls. It's less confusing to speak
of subforms. The subforms of that setf that get evaluated are
r
'b
(progn (setq r nil) 6)
so I think the behavior you describe is a bug (although the description
in CLtL is so ambiguous that the implementors of the respective systems
could easily disagree with me.)
I didn't look inside the Lucid implementation, but in the Symbolics
implementation the source of the bug is that (get-setf-method 'r)
returns NIL, NIL, (#:G6411), (SETQ R #:G6411), R, whereas it should
return (#:G6410), (R), (#:G6411), (SETQ R #:G6411), #:G6410. See
CLtL page 104 for the description of the meaning of these values.
Changing it to return the latter makes your SETF example behave as you
expected, evaluating R -before- bashing it, and setq'ing it to the updated
property list -after- setq'ing it to nil.
Franz Inc.'s Common Lisp ("Allegro CL") ends up with r = nil and
s = (a 1 b 6 c 3). However, it returns the same 5 forms for
(get-setf-method 'r) that Symbolics does, and in fact these 5 forms
are given as an example on p. 105 of CLtL.
∂10-Sep-87 2013 KMP@STONY-BROOK.SCRC.Symbolics.COM setf order of evaluation
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Sep 87 20:13:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 231604; Thu 10-Sep-87 23:13:39 EDT
Date: Thu, 10 Sep 87 23:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: setf order of evaluation
To: franz!ficl!drb@ucbarpa.Berkeley.EDU,
Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: DALY@ibm.com, common-lisp@sail.stanford.edu,
KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8709092139.AA02338@ficl>
Message-ID: <870910231312.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I believe the root of this problem is bad interplay between the
following two design issues:
* I think it was a big mistake to make (SETF var val) work.
Anyone who's ever implemented SETF knows there's something
strange about variables that they have to be handled so
differently than structure accessors. The sense in which
SETQ makes a side-effect (to a structure which is effectively
not user-accessible as a first-class object (in dialects not
having a LOCF extension)) is different than the sense in
which RPLACA makes a side-effect.
The fact that
(DEFUN F (X Y) (PUSH X Y) Y)
is so radically different in its I/O behavior than
(DEFUN F (X Y) (PUSH X (CDR Y)) Y)
is symptomatic of the problem I'm citing.
* I think there's something odd about GETF in that it takes
a place as an argument, but nothing can enforce that. eg,
(GETF '(A B C D) 'C) works, even though (QUOTE ...) is not
a place. If you try to SETF it, you see the error of your
ways. The fact that SETF has to reach through the GETF to
get its first argument and fool with it is what leads to a
problem like the one I was mentioning above.
I don't think there's much we can do about this (short of documenting
clearly how this particular special case (and others like it) should be
dealt with). I think it's doomed to be somewhat of an embarrassment
because we've chosen to create a system of rules which I think
inherently cannot generalize in a completely satisfying way.
I'm not advocating that we change SETF at this late date, but if I were
designing a new language, I'd sure advocate doing things differently.
As food for thought, consider the following examples...
;; #1: The case in question (using a variable as a place)
(PROGN (SETQ R '(A 1 B 2 C 3))
(SETQ S R)
(SETF (GETF R 'B) (PROGN (SETQ R NIL) 6))
(VALUES R S))
;; #2: The case in question (using a non-variable as a place)
(PROGN (SETQ R '(A 1 B 2 C 3))
(SETQ S R)
(SETF (GETF (NTHCDR 2 R) 'B) (PROGN (SETQ R NIL) 6))
(VALUES R S))
;; #3: This can't work, but think hard about why not.
;; There's a sense in which it feels like it ought to be identical
;; to #1 above.
(PROGN (SETQ R '(A 1 B 2 C 3))
(SETQ S R)
(SETF (GETF (NTHCDR 0 R) 'B) (PROGN (SETQ R NIL) 6))
(VALUES R S))
;; #4: This is not as much like the others, but I found its return
;; value to be instructive anyway.
(PROGN (SETQ R '(A 1 B 2 C 3))
(SETQ S R)
(SETF (CAR R) (PROGN (SETQ R NIL) 6))
(VALUES R S))
∂11-Sep-87 1144 Moon@STONY-BROOK.SCRC.Symbolics.COM setf order of evaluation
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Sep 87 11:43:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 232057; Fri 11-Sep-87 14:44:54 EDT
Date: Fri, 11 Sep 87 14:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: setf order of evaluation
To: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <870910231312.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870911144430.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 10 Sep 87 23:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
[philosophy for future languages deleted]
As food for thought, consider the following examples...
;; #1: The case in question (using a variable as a place)
(PROGN (SETQ R '(A 1 B 2 C 3))
(SETQ S R)
(SETF (GETF R 'B) (PROGN (SETQ R NIL) 6))
(VALUES R S))
;; #2: The case in question (using a non-variable as a place)
(PROGN (SETQ R '(A 1 B 2 C 3))
(SETQ S R)
(SETF (GETF (NTHCDR 2 R) 'B) (PROGN (SETQ R NIL) 6))
(VALUES R S))
Definitely an illuminating case. This blows up trying to RPLACD NIL
with the get-setf-method of variables prescribed by CLtL, but does
what one would expect with the get-setf-method of variables I suggested
the other day. Also illuminating:
;; #2a: doesn't use GETF at all
(PROGN (SETQ R '(A 1 B 2 C 3))
(SETQ S R)
(SETF (NTHCDR 2 R) (PROGN (SETQ R NIL) 6))
(VALUES R S))
which again blows up with CLtL's setf-method for variables, but does
what one would expect with the one I suggested. These two examples
changed my mind; now I think the one I suggested is obviously right,
and the one in CLtL, evidently used by Symbolics and Lucid (and no
doubt other implementations) is obviously wrong.
;; #3: This can't work, but think hard about why not.
Works fine for me, and returns the same values as #1.
;; There's a sense in which it feels like it ought to be identical
;; to #1 above.
(PROGN (SETQ R '(A 1 B 2 C 3))
(SETQ S R)
(SETF (GETF (NTHCDR 0 R) 'B) (PROGN (SETQ R NIL) 6))
(VALUES R S))
;; #4: This is not as much like the others, but I found its return
;; value to be instructive anyway.
(PROGN (SETQ R '(A 1 B 2 C 3))
(SETQ S R)
(SETF (CAR R) (PROGN (SETQ R NIL) 6))
(VALUES R S))
Nothing surprising here.
∂11-Sep-87 2240 @RELAY.CS.NET:HELLER@cs.umass.edu RE: setf order of evaluation
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 11 Sep 87 22:40:27 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ag06485; 12 Sep 87 1:40 EDT
Received: from cs.umass.edu by RELAY.CS.NET id an18149; 12 Sep 87 1:31 EDT
Date: Fri, 11 Sep 87 09:45 EDT
From: Stride 440 User <HELLER%cs.umass.edu@RELAY.CS.NET>
Subject: RE: setf order of evaluation
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"common-lisp@sail.stanford.edu"
> From: Timothy Daly <DALY@ibm.com>
> To: common-lisp@SAIL.STANFORD.EDU
>
> Given
>
> (setq r '(a 1 b 2 c 3))
> (setq s r)
> (setf (getf r 'b) (progn (setq r nil) 6))
>
> what is the value of R and S?
>
> Note that P97 of CLtL states that SETF guarantees the
> left-to-right order of evaluation of its arguments.
>
> (yes, i know it is crufty to change R).
>
> Both Symbolics and Lucid seem to generate
> R = (B 8) and S = (A 1 B 2 C 3)
VAXLISP Version U2.2 does the same thing:
LLVS (ll)> (setq r '(a 1 b 2 c 3)) ...
(a 1 b 2 c 3)
LLVS (ll)> (setq s r) ...
(a 1 b 2 c 3)
LLVS (ll)> (setf (getf r 'b) (progn (setq r nil) 6)) ...
6
LLVS (ll)> s ...
(a 1 b 2 c 3)
LLVS (ll)> r ...
(b 6)
LLVS (ll)> (get-setf-method '(getf r b)) ...
(#:g430)
(b)
(#:g429)
(do* ((#:g431 r)
(#:g432 #:g431 (cddr #:g432)))
((atom #:g432)
(let ((#:g428 (list* #:g430 #:g429 #:g431))) (setq r #:g428))
#:g429)
(cond ((atom (cdr #:g432))
(error "Odd length property list in SETF of GETF."))
((eq (car #:g432) #:g430)
(rplaca (cdr #:g432) #:g429)
(return #:g429))))
(getf r #:g430 nil)
LLVS (ll)> (setq r '(a 1 b 2 c 3)) ...
(a 1 b 2 c 3)
LLVS (ll)> (setq s r) ...
(a 1 b 2 c 3)
LLVS (ll)> (macroexpand '(setf (getf r 'b) (progn (setq r nil) 6))) ...
(let* ((#:g446 'b)
(#:g445 (progn
(setq r nil)
6)))
(do* ((#:g447 r)
(#:g448 #:g447 (cddr #:g448)))
((atom #:g448)
(let ((#:g444 (list* #:g446 #:g445 #:g447))) (setq r #:g444))
#:g445)
(cond ((atom (cdr #:g448))
(error "Odd length property list in SETF of GETF."))
((eq (car #:g448) #:g446)
(rplaca (cdr #:g448) #:g445)
(return #:g445)))))
t
Robert Heller
ARPANet: Heller@CS.UMass.EDU
BITNET: Heller@UMass.BITNET
BIX: Heller
GEnie: RHeller
FidoNet: 321/148 (Locks Hill BBS, Wendell, MA)
CompuServe 71450,3432
Local PV VAXen: COINS::HELLER
UCC Cyber/DG: Heller@CS
∂18-Sep-87 1143 gls@Think.COM [KAHLE@Aquinas.Think.COM: defstruct request for common lisp]
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 87 11:43:02 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 18 Sep 87 14:42:55 EDT
Received: by kali.think.com; Fri, 18 Sep 87 14:43:08 EDT
Date: Fri, 18 Sep 87 14:43:08 EDT
From: gls@Think.COM
Message-Id: <8709181843.AA01280@kali.think.com>
To: common-lisp@sail.stanford.edu
Subject: [KAHLE@Aquinas.Think.COM: defstruct request for common lisp]
Date: Sat, 12 Sep 87 17:07 EDT
From: Brewster Kahle <KAHLE@Aquinas.Think.COM>
Subject: defstruct request for common lisp
To: gls@godot.think.com
Moon: 4 days, 22 hours, 25 minutes since the full moon.
I wish there were a function like:
(struction-slots <structure-name>) that returns the list of slots of a
defstruct.
The obvious extension of this is to return the declarations and all, but
I have never needed any of these.
Im sure there are some hairy issues that I do not understand (like
include), but I have wanted the vanilla version many times.
-brewster
∂18-Sep-87 1234 gls@Think.COM [KAHLE@Aquinas.Think.COM: common lisp question]
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 87 12:33:33 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Fri, 18 Sep 87 15:33:07 EDT
Received: by kali.think.com; Fri, 18 Sep 87 15:33:21 EDT
Date: Fri, 18 Sep 87 15:33:21 EDT
From: gls@Think.COM
Message-Id: <8709181933.AA01314@kali.think.com>
To: common-lisp@sail.stanford.edu
Cc: kahle@Think.COM
Subject: [KAHLE@Aquinas.Think.COM: common lisp question]
Date: Wed, 16 Sep 87 17:25 EDT
From: Brewster Kahle <KAHLE@Aquinas.Think.COM>
Subject: common lisp question
To: gls@godot.think.com, mincy@godot.think.com
Moon: 1 day, 13 hours, 32 minutes since the last quarter of the moon.
I want to make a stucture that is printed as
#S(death-row :person 2 :crime 3)
but I want it to be readable by a machine that thinks
there is only the :person slot. ie
(defstruct (death-row :constructor 'something-special)
:person)
Basically I would like to specify the arguments to the constructor to be
(defun make-death-row (&rest keywords &key person &allow-other-keys)
...)
is this possible? If it isnt then structures are limited as a
communication medium between potentially different software versions.
-brewster
∂21-Sep-87 0657 DLW@ALDERAAN.SCRC.Symbolics.COM [KAHLE@Aquinas.Think.COM: defstruct request for common lisp]
Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 21 Sep 87 06:57:27 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121448; Mon 21-Sep-87 09:50:39 EDT
Date: Mon, 21 Sep 87 09:50 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: [KAHLE@Aquinas.Think.COM: defstruct request for common lisp]
To: gls@Think.COM, common-lisp@sail.stanford.edu
In-Reply-To: <8709181843.AA01280@kali.think.com>
Message-ID: <870921095059.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Fri, 18 Sep 87 14:43:08 EDT
From: gls@Think.COM
Date: Sat, 12 Sep 87 17:07 EDT
From: Brewster Kahle <KAHLE@Aquinas.Think.COM>
Subject: defstruct request for common lisp
To: gls@godot.think.com
Moon: 4 days, 22 hours, 25 minutes since the full moon.
I wish there were a function like:
(struction-slots <structure-name>) that returns the list of slots of a
defstruct.
The obvious extension of this is to return the declarations and all, but
I have never needed any of these.
Im sure there are some hairy issues that I do not understand (like
include), but I have wanted the vanilla version many times.
-brewster
One idea that's been discussed that would do what you want, in fact do
something more general, is to redefine structures in terms of
object-oriented programming, if and after CLOS is accepted as part of
Common Lisp. The basic idea is that CLOS would have a defined mechanism
for talking about slots and their properties. I don't know whether
this idea is still current; I suspect it's mainly on the back burner
while the CLOS proposal itself is being finished.
∂21-Sep-87 0701 DLW@ALDERAAN.SCRC.Symbolics.COM [KAHLE@Aquinas.Think.COM: common lisp question]
Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 21 Sep 87 06:57:42 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121449; Mon 21-Sep-87 09:54:50 EDT
Date: Mon, 21 Sep 87 09:55 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: [KAHLE@Aquinas.Think.COM: common lisp question]
To: gls@Think.COM, common-lisp@sail.stanford.edu
cc: kahle@Think.COM
In-Reply-To: <8709181933.AA01314@kali.think.com>
Message-ID: <870921095514.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Fri, 18 Sep 87 15:33:21 EDT
From: gls@Think.COM
Date: Wed, 16 Sep 87 17:25 EDT
From: Brewster Kahle <KAHLE@Aquinas.Think.COM>
To: gls@godot.think.com, mincy@godot.think.com
Moon: 1 day, 13 hours, 32 minutes since the last quarter of the moon.
I want to make a stucture that is printed as
#S(death-row :person 2 :crime 3)
but I want it to be readable by a machine that thinks
there is only the :person slot. ie
(defstruct (death-row :constructor 'something-special)
:person)
Basically I would like to specify the arguments to the constructor to be
(defun make-death-row (&rest keywords &key person &allow-other-keys)
...)
is this possible? If it isnt then structures are limited as a
communication medium between potentially different software versions.
It's not structures that are limited, it's PRINT.
Suppose you chose to represent a death-row instance as a list with two
elements, CRIME and PERSON, in which the extractor for person was a
macro that expanded to CADR. Then you try to transmit that to a
software version that doesn't store CRIME, just PERSON, and uses CAR to
extract the person. It would still fail, although not quite at the same
time. The point is that you need to communicate at a higher level of
abstraction than the raw Lisp data structures represented by raw Lisp
PRINT.
∂21-Sep-87 1410 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: setf order of evaluation
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Sep 87 14:10:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 238035; Mon 21-Sep-87 17:11:32 EDT
Date: Mon, 21 Sep 87 17:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: setf order of evaluation
To: NGALL@G.BBN.COM
cc: DALY@IBM.COM, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <[G.BBN.COM]10-Sep-87 10:40:24.NGALL>
Message-ID: <870921171049.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 10 Sep 1987 10:40-EDT
From: NGALL@G.BBN.COM
Date: Wed, 9 Sep 87 14:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I didn't look inside the Lucid implementation, but in the Symbolics
implementation the source of the bug is that (get-setf-method 'r)
returns NIL, NIL, (#:G6411), (SETQ R #:G6411), R, whereas it should
return (#:G6410), (R), (#:G6411), (SETQ R #:G6411), #:G6410. See
CLtL page 104 for the description of the meaning of these values.
Changing it to return the latter makes your SETF example behave as you
expected, evaluating R -before- bashing it, and setq'ing it to the updated
property list -after- setq'ing it to nil.
Unfortunately, on pg 105 the setf method for the variable X is defined
to be () () (#:g0001) (setq X #:g0001) X. So if this is the right
place to fix things, then CLtL must be fixed too. This is fine with
me, but it would make SETF methods less efficient (or require them to
be more intelligent about optimizing).
I'm told Symbolics will be fixing our next release to do what I said I
thought was right, rather than what CLtL says. I guess that obligates me
to write this up and submit it to the cleanup committee, which I will do.
I don't take the efficiency issue very seriously; it's very easy to
optimize the cases in question, in my opinion.
∂22-Sep-87 1359 KARSAIG1%VUENGVAX.BITNET@forsythe.stanford.edu BBS
Received: from LINDY.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87 13:59:24 PDT
Received: by lindy.stanford.edu; Tue, 22 Sep 87 13:59:45 PDT
Received: by Forsythe.Stanford.EDU; Tue, 22 Sep 87 12:56:50 PDT
Date: Tue, 22 Sep 87 14:53 CDT
From: <KARSAIG1%VUENGVAX.BITNET@forsythe.stanford.edu>
Subject: BBS
To: common-lisp@sail.stanford.edu
X-Original-To: common-lisp@SAIL.STANFORD.EDU, KARSAIG1
Could you include me in your mailing list ? Thanks,
Gabor Karsai
Internet: KARSAIG1%VUENGVAX.BITNET@WISCVM.WIS.EDU
∂23-Sep-87 0059 shebs%orion@cs.utah.edu Bigger Benchmarks
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87 15:28:16 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA15822; Tue, 22 Sep 87 16:27:58 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA06472; Tue, 22 Sep 87 16:27:53 MDT
Date: Tue, 22 Sep 87 16:27:53 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8709222227.AA06472@orion.utah.edu>
To: common-lisp@sail.stanford.edu
Subject: Bigger Benchmarks
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
Does anybody have any benchmarks larger and more complex than the Gabriel
benchmarks? I'm especially interested in those that use a variety of data
structures and that are CPU rather than I/O intensive. A more complete use
of CL is desirable also. Suggestions or code equally welcome...
stan
∂23-Sep-87 0059 newman.pasa@Xerox.COM Common Lisp 3270 emulation available?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 14:34:30 PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 22 SEP 87 14:30:16 PDT
Date: 22 Sep 87 14:30 PDT
From: newman.pasa@Xerox.COM
Subject: Common Lisp 3270 emulation available?
To: common-lisp@sail.stanford.edu
cc: newman.pasa@Xerox.COM
Message-ID: <870922-143016-12618@Xerox>
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
All,
Is there a common lisp implementation of IBM 3270 terminal emulation
available anywhere? Please reply to me, as I do not subscribe to this
distribution list.
Thanks,
>>Dave
∂23-Sep-87 1111 NGALL@G.BBN.COM Re: [KAHLE@Aquinas.Think.COM: common lisp question]
Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 15:41:19 PDT
Date: 22 Sep 1987 18:38-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: [KAHLE@Aquinas.Think.COM: common lisp question]
From: NGALL@G.BBN.COM
To: gls@THINK.COM
Cc: common-lisp@SAIL.STANFORD.EDU, kahle@THINK.COM
Message-ID: <[G.BBN.COM]22-Sep-87 18:38:35.NGALL>
In-Reply-To: <8709181933.AA01314@kali.think.com>
Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error.
How about defining a print-function for your structure that printed
#.(make-death-row :person 2 :crime 3 :allow-other-keys t)
It's the simplest solution I can think of. In the current CLtL you
can't use &key in a boa-constructor lambda-list, and besides, you
couldn't make #S use it anyway (it only uses the 'standard'
constructor {whatever that is}). So, the next easiest solution is
probably redefine the dispatch-reader-macro for S to handle a list
beginning with DEATH-ROW as a special case.
-- Nick
Date: Fri, 18 Sep 87 15:33:21 EDT
From: gls@Think.COM
Date: Wed, 16 Sep 87 17:25 EDT
From: Brewster Kahle <KAHLE@Aquinas.Think.COM>
Subject: common lisp question
To: gls@godot.think.com, mincy@godot.think.com
Moon: 1 day, 13 hours, 32 minutes since the last quarter of the moon.
I want to make a stucture that is printed as
#S(death-row :person 2 :crime 3)
but I want it to be readable by a machine that thinks
there is only the :person slot. ie
(defstruct (death-row :constructor 'something-special)
:person)
Basically I would like to specify the arguments to the constructor to be
(defun make-death-row (&rest keywords &key person &allow-other-keys)
...)
is this possible? If it isnt then structures are limited as a
communication medium between potentially different software versions.
-brewster
∂23-Sep-87 2013 @RELAY.CS.NET:DON@atc.bendix.com Synonym streams
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Sep 87 20:13:25 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac22322; 23 Sep 87 23:19 EDT
Received: from atc.bendix.com by RELAY.CS.NET id ac07602; 23 Sep 87 23:09 EDT
Date: Wed, 23 Sep 87 15:34 EDT
From: DON%atc.bendix.com@RELAY.CS.NET
Subject: Synonym streams
To: common-lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"common-lisp@sail.stanford.edu"
Is a synonym-stream a stream? Can a stream be a synonym of a synonym-stream?
On the LMI, I tried
(defvar *describe-output* (make-synonym-stream '*standard-output*))
Because *standard-output* is by default a synonym of *terminal-io*, *describe-
output* became a synonym for a synonym. When I tried printing to
*describe-stream*, the system hung. It did not hang if I used *terminal-io*
in place of *standard-output*.
LMI's technical support agreed that in spirit it should work; however, CLtL
is ambiguous or at least not complete.
The problem, of course, is that if a synonym-stream is a stream but cannot
be the synonym for another stream, then there must be some function for
testing whether a stream is a synonym or a real stream. (synonym-stream-p).
Do other systems support using *standard-output* as a synonym?
Don Mitchell Don@atc.bendix.com
Bendix Aero. Tech. Ctr. Don%atc.bendix.com@relay.cs.net
9140 Old Annapolis Rd. (301)964-4156
Columbia, MD 21045
∂23-Sep-87 2207 NGALL@G.BBN.COM Re: setf order of evaluation
Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 23 Sep 87 22:06:51 PDT
Date: 24 Sep 1987 01:04-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: setf order of evaluation
From: NGALL@G.BBN.COM
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: common-lisp@SAIL.STANFORD.EDU
Message-ID: <[G.BBN.COM]24-Sep-87 01:04:44.NGALL>
In-Reply-To: <870911144430.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 11 Sep 87 14:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 10 Sep 87 23:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
...
;; #2: The case in question (using a non-variable as a place)
(PROGN (SETQ R '(A 1 B 2 C 3))
(SETQ S R)
(SETF (GETF (NTHCDR 2 R) 'B) (PROGN (SETQ R NIL) 6))
(VALUES R S))
...
;; #2a: doesn't use GETF at all
(PROGN (SETQ R '(A 1 B 2 C 3))
(SETQ S R)
(SETF (NTHCDR 2 R) (PROGN (SETQ R NIL) 6))
(VALUES R S))
which again blows up with CLtL's setf-method for variables, but does
what one would expect with the one I suggested. These two examples
changed my mind; now I think the one I suggested is obviously right,
and the one in CLtL, evidently used by Symbolics and Lucid (and no
doubt other implementations) is obviously wrong.
Minor point: NTHCDR is not a standard generalized variable in CLtL.
Major point: Does the following example change your mind back?
(PROGN (SETQ R (LIST (LIST A 1 B 2 C 3)))
(SETQ S (CAR R))
(SETF (GETF (CAR R) 'B) (PROGN (SETF (CAR R) NIL) 6))
(VALUES R S))
I'll bet that SCL currently returns
(A 1 B 2 C 3) ; ((B 6))
regardless of variable setf-method used. But it should return
(A 1 B 6 C 3) ; (NIL)
As JonL (I think) implicitly pointed out, it is the responsibility of GETF to
evaluate the access-form of the sub-setf-method (e.g., (CAR G0001)).
It is NOT the responsibility of the sub-setf-method. Otherwise the
setf-method for (CAR exp) would have to look like
(G0001 G0002)
(exp (CAR G0001))
(G0003)
(PROGN (RPLACA G0001 G0003) G0003)
G0002
Here's another GETF puzzle (only for implementations that did the
right thing above):
(PROGN (SETF S (LIST (LIST A 1 B 2 C 3)))
(SETF R (CAR S))
(SETF (GETF (CAR S) 'D) (PROG1 4 (SETF (CAR S) NIL)))
(VALUES R S))
could legally return:
#1=(A 1 B 2 C 3) ; (D 4 . #1#) {if new pairs are added to the front}
(A 1 B 2 C 3 D 4) ; NIL {if new pairs are added not at the front, and
the sub-update-form is not used}
#1=(A 1 B 2 C 3 D 4) ; #1# {if new pairs are added not at the front,
and the sub-update-form is used}
One final SETF puzzle:
(PROGN (SETF S (LIST (LIST 1)))
(SETF R (CAR S))
(SETF (CAAR S) (PROG1 2 (SETF (CAR S) (LIST NIL))))
(VALUES R S))
Is this valid?
(1) ; ((2)) {I think: Yes definitely.}
Is this?
(2) ; ((NIL)) {I think: Probably not.}
Try it in your implementation.
Hint: The big issue here is when the setf-method gets a handle on
the object whose cell is being stored into. The definition of DEFSETF
strongly implies that the first choice is the correct one.
-- Nick
∂24-Sep-87 0312 @RELAY.CS.NET:yuasa%kurims.kurims.kyoto-u.junet@UTOKYO-RELAY.CSNET Japanese Activities toward Lisp Standardization
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 24 Sep 87 03:12:21 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa25267; 24 Sep 87 6:13 EDT
Received: from utokyo-relay by RELAY.CS.NET id ax09298; 24 Sep 87 5:59 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA23712; Thu, 24 Sep 87 17:39:28 JST
Received: by titcca.cc.titech.junet (4.12/6.2Junet)
id AA00456; Thu, 24 Sep 87 17:14:08 jst
Received: by nttlab.NTT (4.12/6.2NTT.g) with TCP; Thu, 24 Sep 87 15:58:29 jst
Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet)
id AA16002; Thu, 24 Sep 87 14:50:16 jst
Received: by kurims.kurims.kyoto-u.junet (3.2/6.2Junet)
id AA01955; Thu, 24 Sep 87 14:35:50 JST
Date: Thu, 24 Sep 87 14:35:50 JST
From: Taiichi Yuasa <yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <yuasa@kurims.kurims.kyoto-u.junet>
Message-Id: <8709240535.AA01955@kurims.kurims.kyoto-u.junet>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Japanese Activities toward Lisp Standardization
Japanese Activities toward Lisp Standardization
The demand for Lisp standardization has been growing rapidly in Japanese
computer industries and academic organizations. AIST (Agency of Industrial
Science and Technology), which is responsible for Japan Industrial Standards
(JIS in short), has initiated its activity toward JIS Lisp standardization.
In April 1986, in response to the request from AIST, a working group for Lisp
standardization was formed at JEIDA (Japan Electronic Industry Development
Association). After one year's preliminary discussions, the following
committee "JEIDA Committee for Lisp Standardization" was formed and its
active efforts have begun in June 1987. The aim of this committee is to
develop a Lisp language specification suitable for JIS standard in cooperation
with ISO and the organizations for Lisp standardization in other countries.
JEIDA Committee for Lisp Standardization
----------------------------------------
Chairman:
Takayasu Ito (Tohoku University)
Secretaries:
Tsuneo Furuyama (NTT: Nippon Telegraph and Telephone Corp.)
Fumio Motoyoshi (ETL: Electrotechnical Laboratory)
Taiichi Yuasa (Kyoto University)
Members from Major Computer Companies:
Fujitsu Ltd.
Hitachi Ltd.
IBM Japan Ltd.
Mitsubishi Electric Corp.
NEC Corp.
Oki Electric Industry Co. Ltd.
Toshiba Corp.
Observers:
Masayuki Ida (Aoyama Gakuin University)
Tetsuo Ida (The Institute of Physical and Chemical Research)
Ryo Kamito (AIST)
Masakazu Nakanishi (Keio University)
Takehisa Nireki (JEIDA)
Kentaro Shimizu (University of Tokyo)
Technical issues for Lisp standardization will be discussed by the subsidiary
working group "JEIDA Technical Working Group for Lisp Standardization", or
TG/A in short. This group started technical discussions soon after it was
formed in August 1987. It has been agreed that Common Lisp is a good starting
point for technical discussions. But various technical deficiencies of Common
Lisp have been already pointed out at TG/A. The role of TG/A is to clear up
major technical issues for Lisp standardization, continuing detailed technical
examinations on Common Lisp and other Lisp dialects.
JEIDA Technical Working Group for Lisp Standardization
------------------------------------------------------
Chairman:
Taiichi Yuasa (Research Institute for Mathematical Sciences,
Kyoto University)
Members:
Takashi Chikayama (ICOT)
Etsuya Shibayama (Dept. of Information Science,
Tokyo Institute of Technology)
Kentaro Shimizu (Dept. of Information Science, University of Tokyo)
Akikazu Takeuchi (Central Research Lab., Mitsubishi Electric Corp.)
Kyoji Umemura (NTT Software Lab., NTT)
Advisors:
Toshiaki Kurokawa (Tokyo Research Lab., IBM Japan Ltd.)
Michiaki Yasumura (Central Research Lab., Hitachi Ltd.)
Anyone interested in Japanese activities for Lisp standardization should
contact:
Professor Takayasu Ito
Department of Information Engineering
School of Engineering
Tohoku University
Sendai 980, Japan
Junet: chairlsp@nttlab.ntt.junet
or
Dr. Taiichi Yuasa
Research Institute for Mathematical Sciences
Kyoto University
Kyoto 606, Japan
Junet: yuasa@kurims.kurims.kyoto-u.junet
∂24-Sep-87 1210 Masinter.pa@Xerox.COM STREAM-CLASS-ACCESS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Sep 87 12:10:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 SEP 87 12:08:39 PDT
Date: 24 Sep 87 12:08 PDT
From: Masinter.pa@Xerox.COM
Subject: STREAM-CLASS-ACCESS
In-reply-to: "DON%atc.bendix.com%RELAY.CS.NET":GV:Xerox's message of 23
Sep 87 20:49
To: DON%atc.bendix.com@RELAY.CS.NET
cc: common-lisp@sail.stanford.edu
Message-ID: <870924-120839-15432@Xerox>
I can't find any responses to this mail. I wonder if some of the stream
options might be easier to access if STREAM were a class under CLOS.
Date: Fri, 19 Dec 86 15:19 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FOLLOW-SYNONYM-STREAM
To: Common-Lisp@SAIL.STANFORD.EDU
Message-ID: <861219151955.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
From time to time, I find myself doing:
(LET ((*TERMINAL-IO* *STANDARD-OUTPUT*))
...)
in a multi-window system in order to temporarily change my interaction
to the
same window as output has been redirected to. On the Lisp Machine (and
probably
on many or most other implementations), *STANDARD-OUTPUT* can sometimes
(often)
contain a synonym-stream for *TERMINAL-IO* and the result of the
operation
above is to send output to a stream which is a (circular) synonym for
itself.
The kind of lossage this results in is fairly severe because *DEBUG-IO*
is often
a synonym for *TERMINAL-IO* and if that is in turn a synonym for
*TERMINAL-IO*,
then the debugger cannot run.
A couple of things would make this problem more tractable:
SYNONYM-STREAM-P object [Function]
This accepts any kind of argument. If the argument is not a synonym
stream, then NIL is returned. If the argument is a synonym stream,
then the symbol for which the object is a synonym is returned.
FOLLOW-SYNONYM-STREAM stream [Function]
This accepts a stream and returns the result of following that stream
through any number of synonym stream indirections (including zero).
While I'm on page 329, I think we should also have the following
functions
(or functionalities) which I have needed at other times:
BROADCAST-STREAM-P object [Function]
CONCATENATED-STREAM-P stream [Function]
TWO-WAY-STREAM-P [Function]
...
This accepts any kind of argument. It returns T if the argument is a
{concatenated/broadcast/two-way/...} stream and NIL if the argument is
any other kind of stream.
EXPAND-BROADCAST-STREAM broadcast-stream [Function]
EXPAND-CONCATENATED-STREAM concatenated-stream [Function]
EXPAND-TWO-WAY-STREAM two-way-stream [Function]
...
This accepts a {broadcast/concatenated/two-way/...} stream and returns
a list of the streams which were used to compose it (in an order
compatible with the order of arguments to the creation function).
Note: Implementations are allowed, but not required, to return the
same list every time. The result list should not be destructively
modified.
----- End Forwarded Messages -----
∂24-Sep-87 1631 RWK@YUKON.SCRC.Symbolics.COM Synonym streams
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 24 Sep 87 16:31:31 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 266632; Thu 24-Sep-87 19:08:50 EDT
Date: Thu, 24 Sep 87 19:09 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Synonym streams
To: DON%atc.bendix.com@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 23 Sep 87 15:34 EDT from DON%atc.bendix.com@RELAY.CS.NET
Message-ID: <870924190915.8.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Wed, 23 Sep 87 15:34 EDT
From: DON%atc.bendix.com@RELAY.CS.NET
Is a synonym-stream a stream? Can a stream be a synonym of a synonym-stream?
On the LMI, I tried
(defvar *describe-output* (make-synonym-stream '*standard-output*))
Because *standard-output* is by default a synonym of *terminal-io*, *describe-
output* became a synonym for a synonym. When I tried printing to
*describe-stream*, the system hung. It did not hang if I used *terminal-io*
in place of *standard-output*.
LMI's technical support agreed that in spirit it should work; however, CLtL
is ambiguous or at least not complete.
The problem, of course, is that if a synonym-stream is a stream but cannot
be the synonym for another stream, then there must be some function for
testing whether a stream is a synonym or a real stream. (synonym-stream-p).
Do other systems support using *standard-output* as a synonym?
It works in Symbolics Common Lisp. CLtL appears to be completely
unambiguous to my eyes. Yes, it doesn't explicitly state the
logical consequences, but "any operations on the new stream will
be performed on the stream that is then the value of the dynamic variable
named by the @I(symbol)" seems clear enough.
I'm not arguing that there's no need to elucidate further in the next
manual, but that's an editorial issue that I won't take up on this list.
∂25-Sep-87 0930 @BCO-MULTICS.ARPA:Dickson.Multics@HIS-PHOENIX-MULTICS.ARPA Please add us to you mailing list
Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 25 Sep 87 09:30:26 PDT
Received: FROM HIS-PHOENIX-MULTICS.ARPA BY BCO-MULTICS.ARPA WITH dial; 25 SEP 1987 12:25:47 EDT
Date: Fri, 25 Sep 87 09:25 MST
From: Paul Dickson <Dickson@HIS-PHOENIX-MULTICS.ARPA>
Subject: Please add us to you mailing list
Reply-To: Paul Dickson <Dickson%pco@BCO-MULTICS.ARPA>
To: <@BCO-MULTICS.ARPA:Common-Lisp@SAIL.STANFORD.EDU>
Message-ID: <870925162504.600016@HIS-PHOENIX-MULTICS.ARPA>
Please add us to your mailing list. Our mailing address is:
Common-Lisp-mtg%pco @ BCO-Multics.ARPA
Thanks.
Paul Dickson
Dickson%pco@BCO-Multics.ARPA
∂27-Sep-87 1423 kempf%hplabsz@hplabs.HP.COM Re: STREAM-CLASS-ACCESS
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 27 Sep 87 14:23:02 PDT
Received: from hplabsz.hpl.hp.com by hplms2; Sun, 27 Sep 87 14:22:26 pdt
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Sun, 27 Sep 87 15:23:24 pdt
To: Masinter.pa@Xerox.COM
Cc: common-lisp@sail.stanford.edu
Subject: Re: STREAM-CLASS-ACCESS
X-Mailer: mh6.5
In-Reply-To: Your message of 24 Sep 87 12:08:00 -0700.
<870924-120839-15432@Xerox>
Date: Sun, 27 Sep 87 15:23:22 MST
Message-Id: <11726.559776202@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM
> I can't find any responses to this mail. I wonder if some of the stream
> options might be easier to access if STREAM were a class under CLOS.
I would agree with this. It would certainly make writing an extensible
window system, perhaps based on CommonWindows, easier.
Jim Kempf kempf@hplabs.hp.com
∂28-Sep-87 1112 Masinter.pa@Xerox.COM Re: Japanese Activities toward Lisp Standardization
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Sep 87 11:11:29 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 87 11:07:50 PDT
Date: 28 Sep 87 11:04 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Japanese Activities toward Lisp Standardization
In-reply-to: yuasa%kurims.kurims.kyoto-u.junet's message of 24 Sep 87
03:55
To: yuasa%kurims.kurims.kyoto-u.junet@utokyo-relay.cs.net
cc: Common-Lisp@sail.stanford.edu
from: Cl-Cleanup@Sail.stanford.edu
reply-to: CL-Cleanup@Sail.stanford.edu
Message-ID: <870928-110750-18955@Xerox>
In the United States, the X3J13 committee of ANSI is progressing toward
establishing a standard for Lisp. As with TG/A, X3J13 has agreed that
Common Lisp is a good starting point for technical discussions. We have
also been discussing various technical deficiencies of Common Lisp and
proposals for their correction.
The Lisp community as a whole can be best served if there are not too
many standards. We would like to invite a member TG/A to participate in
the discussions of the "cleanup" working group of X3J13, and to bring
forward those technical deficiencies that are of most serious concern to
TG/A. Fortunately, almost all of our work goes on using electronic mail.
We would welcome active participation, argumentation, proposals and
criticisms.
--- The "cleanup" committee
∂29-Sep-87 1349 @BCO-MULTICS.ARPA:May.KBS@HIS-PHOENIX-MULTICS.ARPA New Member Questions
Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 29 Sep 87 13:49:05 PDT
Received: FROM HIS-PHOENIX-MULTICS.ARPA BY BCO-MULTICS.ARPA WITH dial; 29 SEP 1987 16:46:51 EDT
Date: Tue, 29 Sep 87 13:42 MST
From: Bob May <May@HIS-PHOENIX-MULTICS.ARPA>
Subject: New Member Questions
Reply-To: May%pco@BCO-MULTICS.ARPA
To: <@BCO-MULTICS.ARPA:Common-Lisp@SAIL.STANFORD.EDU>
Message-ID: <870929204215.288214@HIS-PHOENIX-MULTICS.ARPA>
Hello. We have just joined this meeting. Would the chairperson send me
info about obtaining the archive files?
I am also trying to find a good connection for the CL-VALIDATION mailing
list that was mentioned a while back. Can someone please post that
information or send me mail?
Thanks,
Robert M. May (Bob)
Honeywell Bull
Phoenix, Arizona
∂30-Sep-87 1350 ghenis.pasa@Xerox.COM Source code non-access (Re: defstruct request)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Sep 87 13:50:45 PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 30 SEP 87 12:20:12 PDT
Date: 30 Sep 87 12:19 PDT
From: ghenis.pasa@Xerox.COM
Subject: Source code non-access (Re: defstruct request)
In-reply-to: gls@Think.COM's message of Fri, 18 Sep 87 14:43:08 EDT
To: gls@Think.COM
cc: common-lisp@sail.stanford.edu
Message-ID: <870930-122012-2377@Xerox>
This looks like a special case of a larger issue in Common Lisp. Unless
I have misread the spec it looks like definitions cannot be
reconstructed programmatically. What I mean is that once you type/load a
DEFSTRUCT, there is no body of CL code that can reconstruct the
expression as originally typed/loaded. This also appears to be true for
DEFUN, DEFMACRO, etc. Please tell me I'm wrong! Interestingly, this
seems to be possible in some implementations of CL when running
interpreted code, only that it is done in implementation-specific
(yeech!) ways.
If it is true that definitions cannot be programmatically reconstructed
in Common Lisp, was this an explicit committee decision?
∂01-Oct-87 0802 FAHLMAN@C.CS.CMU.EDU Source code non-access (Re: defstruct request)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 08:02:04 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 1 Oct 87 10:59:54-EDT
Date: Thu, 1 Oct 1987 10:59 EDT
Message-ID: <FAHLMAN.12339019721.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: ghenis.pasa@XEROX.COM
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Source code non-access (Re: defstruct request)
In-reply-to: Msg of 30 Sep 1987 15:19-EDT from ghenis.pasa at Xerox.COM
If it is true that definitions cannot be programmatically reconstructed
in Common Lisp, was this an explicit committee decision?
It has never been the case in the Maclisp world that all of the
information is the source program is preserved at runtime, especially in
the case where the code you load is compiled. Implementations do
various things to make the original information available for debugging
purposes, but this has always been considered an environment issue -- a
debugging aid, mostly -- and not a part of the language proper. For
example, some implementations "macro-memoize" (replace a macro call with
its expansion) in the interpreter, and many of these expanders keep
track of the original macro form so that the expansion can be undone if
the macro is altered at runtime; some keep track of what forms were
created by character macros in the reader so that the printer can
perform the inverse transform; some annotate each compiled function with
a pointer back into the proper place in the original source file. But
the language spec does not require any of this.
The tradition in Interlisp is different, since the runtime image is
considered to be the primary form of a program with which the user
interacts; in Maclisp, you go back to the source file to make changes,
usually using some Emacs-like editor. Therefore, in Interlisp, all of
the information about a program must be included in or accessible from
the runtime program. The Common Lisp design tries to accommodate this
style of interaction, but not to require it.
I don't think that it was ever an explicit decision of the design group
that the language would not require that all information in the source
be preserved at runtime; it was simply an assumption that was never
challenged. The question did come up whether we should require an
Interlisp-style or an Emacs-style editing environment, and it was clear
that Common Lisp would not be accepted unless it accommodated both
styles, but required neither.
-- Scott
∂01-Oct-87 1816 ghenis.pasa@Xerox.COM Re: [KAHLE@Aquinas.Think.COM: defstruct request for common
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Oct 87 18:16:09 PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 01 OCT 87 17:25:43 PDT
Date: 1 Oct 87 17:25 PDT
Sender: ghenis.pasa@Xerox.COM
Subject: Re: [KAHLE@Aquinas.Think.COM: defstruct request for common
lisp]
In-reply-to: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>'s
message of Mon, 21 Sep 87 09:50 EDT
To: DLW@ALDERAAN.SCRC.Symbolics.COM
cc: gls@Think.COM, common-lisp@sail.stanford.edu, Ghenis.Pasa@Xerox.COM
from: Pablo Ghenis <ghenis.pasa@Xerox.COM>
Message-ID: <871001-172543-4788@Xerox>
I wish there were a function like:
(structure-slots <structure-name>)
that returns the list of slots of a defstruct.
One idea that's been discussed that would do what you want, in
fact do something more general, is to redefine structures in terms
of object-oriented programming, if and after CLOS is accepted as
part of ...
What useful things could one do with the output of (structure-slots
<structure-name>), given that the choice of slot to access cannot be
gracefully deferred until run-time the way p-lists allow? I'm afraid
that a "structure-slots" function wouldn't be all that valuable because
of this deeper limitation of structures.
I'm not knocking structures though. The no-free-lunch rule indicates
that if one wants such dynamic slot selection then there will be a price
to pay at run-time.
What this points out is the current lack of a data structure in CL that
provides a fixed number of named slots AND run-time choice of slot to
access. Perhaps the following table (off the top of my keyboard) can
highlight the characteristics of CL's data structures and the (missing)
functionality that objects will add to the language. This should
graphically reinforce your point that the needs that Brewster Kahle
originally had in mind might be properly addressed only by CLOS
Some Common Lisp Data Structures and their usage
------------------------------------------------
| CLOS
Arrays Structures P-Lists A-Lists | Objects?
|
|
Numerically |
indexed |
access * |
|
"Labeled" |
access * * * | *
|
Fixed # |
of "slots" * * | *
|
Dynamic |
labels (1) * * * | *
|
Destructively |
update * * * (2) | *
(1) The name of the slot to be accessed can be determined at run-time
(impossible with structures, barring some horrible kludge)
(2) Possible but the general case is more trouble than with P-Lists,
where
(setf (getf plist key) newvalue) suffices for old OR NEW keys.
∂01-Oct-87 2025 sandra%orion@cs.utah.edu defstruct slot info
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 20:24:53 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA06847; Thu, 1 Oct 87 21:24:42 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA18914; Thu, 1 Oct 87 21:24:37 MDT
Date: Thu, 1 Oct 87 21:24:37 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710020324.AA18914@orion.utah.edu>
Subject: defstruct slot info
To: common-lisp@sail.stanford.edu
Pablo Ghenis writes:
> What useful things could one do with the output of (structure-slots
> <structure-name>), given that the choice of slot to access cannot be
> gracefully deferred until run-time the way p-lists allow? I'm afraid
> that a "structure-slots" function wouldn't be all that valuable because
> of this deeper limitation of structures.
If the function returned more information than just the slot names --
like the name of the accessor function for each slot, and maybe the
:type and :read-only flags -- then it would be very useful. For
example, I could implement a portable data structure browser.
Basically, I'd like to be able to display a structure as a box with
labelled sub-boxes to show (and maybe modify) the slot values. Without
an inquiry function, about the only alternative is to redefine DEFSTRUCT
to cache the information I need. I definitely want to avoid forcing
users (who are probably having enough troubles already if they're
resorting to the use of this kind of debugging tool) to define a special
"browser" function for each structure type they use, akin to the
structure print function.
My experience is that many (most? all?) implementations already cache at
least the slot descriptor information around somewhere, since it's used
when you :include the structure type in another.
Incidentally, my gripe with structures right now has to do with the
"maybe modify" the slot values part -- because of the reliance on SETF,
I have to construct and EVAL a piece of code, when I would really much
rather just FUNCALL a setter function....
-Sandra
-------
∂02-Oct-87 0502 barmar@Think.COM Re: [KAHLE@Aquinas.Think.COM: defstruct request for common
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Oct 87 05:02:01 PDT
Return-Path: <barmar@Think.COM>
Received: from occam by Think.COM via CHAOS; Thu, 1 Oct 87 23:14:21 EDT
Date: Thu, 1 Oct 87 23:16 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: [KAHLE@Aquinas.Think.COM: defstruct request for common
lisp]
To: Pablo Ghenis <ghenis.pasa@xerox.com>
Cc: DLW@alderaan.scrc.symbolics.com, gls@Think.COM,
common-lisp@sail.stanford.edu
In-Reply-To: <871001-172543-4788@Xerox>
Message-Id: <871001231654.3.BARMAR@OCCAM.THINK.COM>
Date: 1 Oct 87 17:25 PDT
From: Pablo Ghenis <ghenis.pasa@xerox.com>
What useful things could one do with the output of (structure-slots
<structure-name>), given that the choice of slot to access cannot be
gracefully deferred until run-time the way p-lists allow? I'm afraid
that a "structure-slots" function wouldn't be all that valuable because
of this deeper limitation of structures.
What limitation are you talking about? Structure slot names are also
the names of functions, which can be FUNCALLed. Thus, one could write
(defun show-structure-slots (structure)
(dolist (slot (structure-slots (type-of structure)))
(format t "~A: ~S" slot (funcall slot structure))))
You may have been thinking of Maclisp and Zetalisp defstruct, which
defined the accessors as macros, so they couldn't be FUNCALLed. Common
Lisp fixed this.
barmar
∂02-Oct-87 1033 ghenis.pasa@Xerox.COM Re: [KAHLE@Aquinas.Think.COM: defstruct request for common
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Oct 87 10:33:11 PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 02 OCT 87 10:21:21 PDT
Date: 2 Oct 87 10:20 PDT
From: ghenis.pasa@Xerox.COM
Subject: Re: [KAHLE@Aquinas.Think.COM: defstruct request for common
lisp]
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Thu, 1 Oct
87 23:16 EDT
To: barmar@Think.COM
cc: ghenis.pasa@Xerox.COM, common-lisp@sail.stanford.edu
Message-ID: <871002-102121-5691@Xerox>
What limitation are you talking about? Structure slot names
are also the names of functions, which can be FUNCALLed. Thus, one
could write
(defun show-structure-slots (structure)
(dolist (slot (structure-slots (type-of structure)))
(format t "~A: ~S" slot (funcall slot structure))))
Mea culpa for reading too literally. I was (narrowly) thinking of the
semantics of STRUCTURE-SLOTS as returning slot NAMES, which would be of
very little use. Your interpretation could be better called
STRUCTURE-ACCESSORS and its output is truly useful. From that point of
view Kahle's request makes a lot more sense...
Pablo Ghenis
∂05-Oct-87 1141 vgordon@venera.isi.edu CMU Common Lisp Distribution
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 11:41:13 PDT
Posted-Date: Mon, 05 Oct 87 11:41:30 PDT
Message-Id: <8710051841.AA24782@venera.isi.edu>
Received: from LOCALHOST by venera.isi.edu (5.54/5.51)
id AA24782; Mon, 5 Oct 87 11:41:41 PDT
To: Common-Lisp@sail.stanford.edu, AILIST@sri.com
Subject: CMU Common Lisp Distribution
Date: Mon, 05 Oct 87 11:41:30 PDT
From: Vicki L. Gordon <vgordon@venera.isi.edu>
With DARPA funding, the University of Southern California's Information
Sciences Institute (USC/ISI) is serving as a distribution center for
public-domain Common Lisp software packages. The first of these packages
includes the source files for CMU Common Lisp (formerly known as "Spice
Lisp"). The package also includes an unsupported public-domain version
of the OPS5 language that is written in Common Lisp.
If there is sufficient interest, and if funding allows, we will later expand
the distribution program to include additional software packages from other
sources.
CMU Common Lisp is a full implementation of Common Lisp, developed as part of
the Spice project at Carnegie-Mellon University (CMU). This system runs only
on the IBM RT PC, and only under CMU's Mach operating system (superficially
similar to 4.3bsd Unix, but with a different internal organization). Since
the IBM RT version of Mach is not currently supported outside of CMU, it
follows that CMU Common Lisp is *NOT* a system that anyone can obtain and
run as is. We are making the sources for this system available because a
number of groups have found it to be a useful starting point for their own
Common Lisp implementations. Typically, it takes a man-year of effort to port
this system to a new machine and operating system (more if the target
environment is unusual). Individuals and small research groups who want a
Common Lisp for their own use are advised to use one of the commercially
available products.
This source code is in the public domain and, once you have them, there
is no restriction on how you may use them. They are made available as a public
service, with no warranty of any sort by the authors, CMU, or USC/ISI, and
with no promise of future support. CMU Common Lisp has been heavily used at
CMU, but it has not been extensively tested in any systematic way. Questions
about the distribution procedure may be directed via electronic mail to
ACTION@ISI.EDU, or you may call (213) 822-5511. Bug reports and questions
about the code itself should also be directed to SCOTT.FAHLMAN@CS.CMU.EDU.
This distribution package contains approximately 7 megabytes of ASCII source
files. It can be obtained over the Arpanet/Milnet by establishing an FTP
connection to VENERA.ISI.EDU and logging in as "anonymous" (any password can be
used). For optimal response time, please conduct your file transfer during
our non-primetime hours (1800 to 0800 PDT). The source files are kept in the
following directories:
/common-lisp/implementation/cmu/code
(Runtime system and interpreter for CMU Common Lisp on IBM RT PC under Mach)
/common-lisp/implementation/cmu/clc
(Compiler from Common Lisp to native code for RT/Mach. Mostly written in
Common Lisp itself.)
/common-lisp/implementation/cmu/hemlock
(Sources for the Hemlock text editor. This editor is similar at user level to
Emacs. Written in Common Lisp, but contains some Mach-specific system calls
and display code. Uses either X windows or standard termcap terminals.)
/common-lisp/implementation/cmu/OPS5
(Portable Common Lisp version of the OPS5 production-system language.
A quick and dirty port of the public domain version that was developed
originally in Franz Lisp. No support whatsoever is provided.)
/common-lisp/implementation/cmu/miscops
(Low level support routines for the IBM PC RT: garbage collection, generic
arithmetic, etc. Totally machine-specific. Provided as an example of what
needs to be done in order to port this lisp to another machine.)
/common-lisp/implementation/cmu/icode
(Lisp functions implementing the interface between Mach and CMU Common Lisp.
Very system-specific. Provided only as an example.)
/common-lisp/implementation/cmu/lib
(Cursor definition file and spelling dictionary used by the Lisp runtime
system).
If you would like to order a tape, we will first send you a release form
which you are required to sign prior to receiving the tape. When you return
the signed release, include a check made payable to USC/Information Sciences
Institute for $100.00 to cover the production and mailing costs. Please
remember to include a complete return address.
The default tape format will be tar 1600 bpi, unless otherwise specified.
Currently ISI is only prepared to distribute tapes containing the CMU
Common Lisp code to individuals or companies within the United States.
We are currently negotiating with the Department of Commerce and CMU
to obtain authorization to distribute the code to countries outside of
the United States; however, we do not expect approval in the immediate
future.
The following hardcopy documentation produced by CMU is also available
to all recipients at a cost of $20.00 per package (payable to USC/
Information Sciences Institute). The package includes:
- "Internal Design of Common Lisp on the IBM RT PC"
- "CMU Common Lisp User's Manual, Mach/IBM RT PC Edition"
- "Hemlock User's Manual"
- "Hemlock Command Implementor's Manual"
Please send your request for a tape and/or documentation to ACTION@ISI.EDU,
or mail it to the following address:
USC/Information Sciences Institute
Attn: ACTION
4676 Admiralty Way
Marina del Rey, CA 90292
(213) 822-1511 ext 289
∂05-Oct-87 1223 vgordon@venera.isi.edu CMU Common Lisp Distribution
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 11:41:13 PDT
Posted-Date: Mon, 05 Oct 87 11:41:30 PDT
Message-Id: <8710051841.AA24782@venera.isi.edu>
Received: from LOCALHOST by venera.isi.edu (5.54/5.51)
id AA24782; Mon, 5 Oct 87 11:41:41 PDT
To: Common-Lisp@sail.stanford.edu, AILIST@sri.com
Subject: CMU Common Lisp Distribution
Date: Mon, 05 Oct 87 11:41:30 PDT
From: Vicki L. Gordon <vgordon@venera.isi.edu>
With DARPA funding, the University of Southern California's Information
Sciences Institute (USC/ISI) is serving as a distribution center for
public-domain Common Lisp software packages. The first of these packages
includes the source files for CMU Common Lisp (formerly known as "Spice
Lisp"). The package also includes an unsupported public-domain version
of the OPS5 language that is written in Common Lisp.
If there is sufficient interest, and if funding allows, we will later expand
the distribution program to include additional software packages from other
sources.
CMU Common Lisp is a full implementation of Common Lisp, developed as part of
the Spice project at Carnegie-Mellon University (CMU). This system runs only
on the IBM RT PC, and only under CMU's Mach operating system (superficially
similar to 4.3bsd Unix, but with a different internal organization). Since
the IBM RT version of Mach is not currently supported outside of CMU, it
follows that CMU Common Lisp is *NOT* a system that anyone can obtain and
run as is. We are making the sources for this system available because a
number of groups have found it to be a useful starting point for their own
Common Lisp implementations. Typically, it takes a man-year of effort to port
this system to a new machine and operating system (more if the target
environment is unusual). Individuals and small research groups who want a
Common Lisp for their own use are advised to use one of the commercially
available products.
This source code is in the public domain and, once you have them, there
is no restriction on how you may use them. They are made available as a public
service, with no warranty of any sort by the authors, CMU, or USC/ISI, and
with no promise of future support. CMU Common Lisp has been heavily used at
CMU, but it has not been extensively tested in any systematic way. Questions
about the distribution procedure may be directed via electronic mail to
ACTION@ISI.EDU, or you may call (213) 822-5511. Bug reports and questions
about the code itself should also be directed to SCOTT.FAHLMAN@CS.CMU.EDU.
This distribution package contains approximately 7 megabytes of ASCII source
files. It can be obtained over the Arpanet/Milnet by establishing an FTP
connection to VENERA.ISI.EDU and logging in as "anonymous" (any password can be
used). For optimal response time, please conduct your file transfer during
our non-primetime hours (1800 to 0800 PDT). The source files are kept in the
following directories:
/common-lisp/implementation/cmu/code
(Runtime system and interpreter for CMU Common Lisp on IBM RT PC under Mach)
/common-lisp/implementation/cmu/clc
(Compiler from Common Lisp to native code for RT/Mach. Mostly written in
Common Lisp itself.)
/common-lisp/implementation/cmu/hemlock
(Sources for the Hemlock text editor. This editor is similar at user level to
Emacs. Written in Common Lisp, but contains some Mach-specific system calls
and display code. Uses either X windows or standard termcap terminals.)
/common-lisp/implementation/cmu/OPS5
(Portable Common Lisp version of the OPS5 production-system language.
A quick and dirty port of the public domain version that was developed
originally in Franz Lisp. No support whatsoever is provided.)
/common-lisp/implementation/cmu/miscops
(Low level support routines for the IBM PC RT: garbage collection, generic
arithmetic, etc. Totally machine-specific. Provided as an example of what
needs to be done in order to port this lisp to another machine.)
/common-lisp/implementation/cmu/icode
(Lisp functions implementing the interface between Mach and CMU Common Lisp.
Very system-specific. Provided only as an example.)
/common-lisp/implementation/cmu/lib
(Cursor definition file and spelling dictionary used by the Lisp runtime
system).
If you would like to order a tape, we will first send you a release form
which you are required to sign prior to receiving the tape. When you return
the signed release, include a check made payable to USC/Information Sciences
Institute for $100.00 to cover the production and mailing costs. Please
remember to include a complete return address.
The default tape format will be tar 1600 bpi, unless otherwise specified.
Currently ISI is only prepared to distribute tapes containing the CMU
Common Lisp code to individuals or companies within the United States.
We are currently negotiating with the Department of Commerce and CMU
to obtain authorization to distribute the code to countries outside of
the United States; however, we do not expect approval in the immediate
future.
The following hardcopy documentation produced by CMU is also available
to all recipients at a cost of $20.00 per package (payable to USC/
Information Sciences Institute). The package includes:
- "Internal Design of Common Lisp on the IBM RT PC"
- "CMU Common Lisp User's Manual, Mach/IBM RT PC Edition"
- "Hemlock User's Manual"
- "Hemlock Command Implementor's Manual"
Please send your request for a tape and/or documentation to ACTION@ISI.EDU,
or mail it to the following address:
USC/Information Sciences Institute
Attn: ACTION
4676 Admiralty Way
Marina del Rey, CA 90292
(213) 822-1511 ext 289
∂05-Oct-87 1327 vgordon@venera.isi.edu CMU Common Lisp Distribution
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 11:41:13 PDT
Posted-Date: Mon, 05 Oct 87 11:41:30 PDT
Message-Id: <8710051841.AA24782@venera.isi.edu>
Received: from LOCALHOST by venera.isi.edu (5.54/5.51)
id AA24782; Mon, 5 Oct 87 11:41:41 PDT
To: Common-Lisp@sail.stanford.edu, AILIST@sri.com
Subject: CMU Common Lisp Distribution
Date: Mon, 05 Oct 87 11:41:30 PDT
From: Vicki L. Gordon <vgordon@venera.isi.edu>
With DARPA funding, the University of Southern California's Information
Sciences Institute (USC/ISI) is serving as a distribution center for
public-domain Common Lisp software packages. The first of these packages
includes the source files for CMU Common Lisp (formerly known as "Spice
Lisp"). The package also includes an unsupported public-domain version
of the OPS5 language that is written in Common Lisp.
If there is sufficient interest, and if funding allows, we will later expand
the distribution program to include additional software packages from other
sources.
CMU Common Lisp is a full implementation of Common Lisp, developed as part of
the Spice project at Carnegie-Mellon University (CMU). This system runs only
on the IBM RT PC, and only under CMU's Mach operating system (superficially
similar to 4.3bsd Unix, but with a different internal organization). Since
the IBM RT version of Mach is not currently supported outside of CMU, it
follows that CMU Common Lisp is *NOT* a system that anyone can obtain and
run as is. We are making the sources for this system available because a
number of groups have found it to be a useful starting point for their own
Common Lisp implementations. Typically, it takes a man-year of effort to port
this system to a new machine and operating system (more if the target
environment is unusual). Individuals and small research groups who want a
Common Lisp for their own use are advised to use one of the commercially
available products.
This source code is in the public domain and, once you have them, there
is no restriction on how you may use them. They are made available as a public
service, with no warranty of any sort by the authors, CMU, or USC/ISI, and
with no promise of future support. CMU Common Lisp has been heavily used at
CMU, but it has not been extensively tested in any systematic way. Questions
about the distribution procedure may be directed via electronic mail to
ACTION@ISI.EDU, or you may call (213) 822-5511. Bug reports and questions
about the code itself should also be directed to SCOTT.FAHLMAN@CS.CMU.EDU.
This distribution package contains approximately 7 megabytes of ASCII source
files. It can be obtained over the Arpanet/Milnet by establishing an FTP
connection to VENERA.ISI.EDU and logging in as "anonymous" (any password can be
used). For optimal response time, please conduct your file transfer during
our non-primetime hours (1800 to 0800 PDT). The source files are kept in the
following directories:
/common-lisp/implementation/cmu/code
(Runtime system and interpreter for CMU Common Lisp on IBM RT PC under Mach)
/common-lisp/implementation/cmu/clc
(Compiler from Common Lisp to native code for RT/Mach. Mostly written in
Common Lisp itself.)
/common-lisp/implementation/cmu/hemlock
(Sources for the Hemlock text editor. This editor is similar at user level to
Emacs. Written in Common Lisp, but contains some Mach-specific system calls
and display code. Uses either X windows or standard termcap terminals.)
/common-lisp/implementation/cmu/OPS5
(Portable Common Lisp version of the OPS5 production-system language.
A quick and dirty port of the public domain version that was developed
originally in Franz Lisp. No support whatsoever is provided.)
/common-lisp/implementation/cmu/miscops
(Low level support routines for the IBM PC RT: garbage collection, generic
arithmetic, etc. Totally machine-specific. Provided as an example of what
needs to be done in order to port this lisp to another machine.)
/common-lisp/implementation/cmu/icode
(Lisp functions implementing the interface between Mach and CMU Common Lisp.
Very system-specific. Provided only as an example.)
/common-lisp/implementation/cmu/lib
(Cursor definition file and spelling dictionary used by the Lisp runtime
system).
If you would like to order a tape, we will first send you a release form
which you are required to sign prior to receiving the tape. When you return
the signed release, include a check made payable to USC/Information Sciences
Institute for $100.00 to cover the production and mailing costs. Please
remember to include a complete return address.
The default tape format will be tar 1600 bpi, unless otherwise specified.
Currently ISI is only prepared to distribute tapes containing the CMU
Common Lisp code to individuals or companies within the United States.
We are currently negotiating with the Department of Commerce and CMU
to obtain authorization to distribute the code to countries outside of
the United States; however, we do not expect approval in the immediate
future.
The following hardcopy documentation produced by CMU is also available
to all recipients at a cost of $20.00 per package (payable to USC/
Information Sciences Institute). The package includes:
- "Internal Design of Common Lisp on the IBM RT PC"
- "CMU Common Lisp User's Manual, Mach/IBM RT PC Edition"
- "Hemlock User's Manual"
- "Hemlock Command Implementor's Manual"
Please send your request for a tape and/or documentation to ACTION@ISI.EDU,
or mail it to the following address:
USC/Information Sciences Institute
Attn: ACTION
4676 Admiralty Way
Marina del Rey, CA 90292
(213) 822-1511 ext 289
∂05-Oct-87 1337 vgordon@venera.isi.edu CMU Common Lisp Distribution
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 11:41:13 PDT
Posted-Date: Mon, 05 Oct 87 11:41:30 PDT
Message-Id: <8710051841.AA24782@venera.isi.edu>
Received: from LOCALHOST by venera.isi.edu (5.54/5.51)
id AA24782; Mon, 5 Oct 87 11:41:41 PDT
To: Common-Lisp@sail.stanford.edu, AILIST@sri.com
Subject: CMU Common Lisp Distribution
Date: Mon, 05 Oct 87 11:41:30 PDT
From: Vicki L. Gordon <vgordon@venera.isi.edu>
With DARPA funding, the University of Southern California's Information
Sciences Institute (USC/ISI) is serving as a distribution center for
public-domain Common Lisp software packages. The first of these packages
includes the source files for CMU Common Lisp (formerly known as "Spice
Lisp"). The package also includes an unsupported public-domain version
of the OPS5 language that is written in Common Lisp.
If there is sufficient interest, and if funding allows, we will later expand
the distribution program to include additional software packages from other
sources.
CMU Common Lisp is a full implementation of Common Lisp, developed as part of
the Spice project at Carnegie-Mellon University (CMU). This system runs only
on the IBM RT PC, and only under CMU's Mach operating system (superficially
similar to 4.3bsd Unix, but with a different internal organization). Since
the IBM RT version of Mach is not currently supported outside of CMU, it
follows that CMU Common Lisp is *NOT* a system that anyone can obtain and
run as is. We are making the sources for this system available because a
number of groups have found it to be a useful starting point for their own
Common Lisp implementations. Typically, it takes a man-year of effort to port
this system to a new machine and operating system (more if the target
environment is unusual). Individuals and small research groups who want a
Common Lisp for their own use are advised to use one of the commercially
available products.
This source code is in the public domain and, once you have them, there
is no restriction on how you may use them. They are made available as a public
service, with no warranty of any sort by the authors, CMU, or USC/ISI, and
with no promise of future support. CMU Common Lisp has been heavily used at
CMU, but it has not been extensively tested in any systematic way. Questions
about the distribution procedure may be directed via electronic mail to
ACTION@ISI.EDU, or you may call (213) 822-5511. Bug reports and questions
about the code itself should also be directed to SCOTT.FAHLMAN@CS.CMU.EDU.
This distribution package contains approximately 7 megabytes of ASCII source
files. It can be obtained over the Arpanet/Milnet by establishing an FTP
connection to VENERA.ISI.EDU and logging in as "anonymous" (any password can be
used). For optimal response time, please conduct your file transfer during
our non-primetime hours (1800 to 0800 PDT). The source files are kept in the
following directories:
/common-lisp/implementation/cmu/code
(Runtime system and interpreter for CMU Common Lisp on IBM RT PC under Mach)
/common-lisp/implementation/cmu/clc
(Compiler from Common Lisp to native code for RT/Mach. Mostly written in
Common Lisp itself.)
/common-lisp/implementation/cmu/hemlock
(Sources for the Hemlock text editor. This editor is similar at user level to
Emacs. Written in Common Lisp, but contains some Mach-specific system calls
and display code. Uses either X windows or standard termcap terminals.)
/common-lisp/implementation/cmu/OPS5
(Portable Common Lisp version of the OPS5 production-system language.
A quick and dirty port of the public domain version that was developed
originally in Franz Lisp. No support whatsoever is provided.)
/common-lisp/implementation/cmu/miscops
(Low level support routines for the IBM PC RT: garbage collection, generic
arithmetic, etc. Totally machine-specific. Provided as an example of what
needs to be done in order to port this lisp to another machine.)
/common-lisp/implementation/cmu/icode
(Lisp functions implementing the interface between Mach and CMU Common Lisp.
Very system-specific. Provided only as an example.)
/common-lisp/implementation/cmu/lib
(Cursor definition file and spelling dictionary used by the Lisp runtime
system).
If you would like to order a tape, we will first send you a release form
which you are required to sign prior to receiving the tape. When you return
the signed release, include a check made payable to USC/Information Sciences
Institute for $100.00 to cover the production and mailing costs. Please
remember to include a complete return address.
The default tape format will be tar 1600 bpi, unless otherwise specified.
Currently ISI is only prepared to distribute tapes containing the CMU
Common Lisp code to individuals or companies within the United States.
We are currently negotiating with the Department of Commerce and CMU
to obtain authorization to distribute the code to countries outside of
the United States; however, we do not expect approval in the immediate
future.
The following hardcopy documentation produced by CMU is also available
to all recipients at a cost of $20.00 per package (payable to USC/
Information Sciences Institute). The package includes:
- "Internal Design of Common Lisp on the IBM RT PC"
- "CMU Common Lisp User's Manual, Mach/IBM RT PC Edition"
- "Hemlock User's Manual"
- "Hemlock Command Implementor's Manual"
Please send your request for a tape and/or documentation to ACTION@ISI.EDU,
or mail it to the following address:
USC/Information Sciences Institute
Attn: ACTION
4676 Admiralty Way
Marina del Rey, CA 90292
(213) 822-1511 ext 289
∂05-Oct-87 2308 ME SAIL domain mailer test
To: common-lisp@SAIL.Stanford.EDU
This is a test of the SAIL domain mailer. This message, though addressed
to Common-Lisp@SAIL, is not expected actually to get out to any network
addresses, but in case it does, I apologize in advance. The new domain
mailer may be having some storage problem with big lists such as the
Common-Lisp list, so this test is important to check that out.
∂06-Oct-87 0122 pyrnj!pyramid!bein@RUTGERS.EDU multiple-value-bind pervasive-ness ...
Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 6 Oct 87 01:21:54 PDT
Received: by RUTGERS.EDU (5.54/1.14) with UUCP
id AA07346; Tue, 6 Oct 87 04:03:52 EDT
Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424)
id AA05751; Mon, 5 Oct 87 23:29:04 PDT
Received: by pyrnova.pyramid.COM (5.52/OSx4.0b-870424)
id AA18870; Mon, 5 Oct 87 23:30:56 PDT
Date: 5 Oct 1987 23:23-PDT
From: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Subject: multiple-value-bind pervasive-ness ...
To: common-lisp@sail.stanford.edu@RUTGERS.EDU
Message-Id: <560499808/bein@pyrnova>
I know this must have come up before ..
Is the scope of the declarations in a multiple-value-bind to
include to evaluation of the form which produces the multiple-values?
For example ...
(SETQ A :SPECIAL-A)
(DEFUN HACK (A)
(MULTIPLE-VALUE-BIND (A SECOND-VALUE)
(VALUES A 'DUMMY)
(DECLARE (SPECIAL A))
(LIST A SECOND-VALUE)))
Should (HACK :LEXICAL-A) return (:SPECIAL-A DUMMY) or (:LEXICAL-A DUMMY) ?
The reason for the second-value is to avoid what a compiler
might do as a rewrite to a let binding in which case the
answer is fairly clear. If the answer is that the declaration
does NOT apply to the evaluation of the value producing
form, then a rewrite into the most obvious let is of course illegal.
--David
∂06-Oct-87 2305 @RELAY.CS.NET:GALLAGHER@cs.umass.edu Extending Defstruct
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Oct 87 23:04:56 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab03913; 7 Oct 87 1:24 EDT
Received: from cs.umass.edu by RELAY.CS.NET id de12948; 7 Oct 87 1:22 EDT
Date: Tue, 6 Oct 87 18:39 EDT
From: Kevin Gallagher <GALLAGHER%cs.umass.edu@RELAY.CS.NET>
Subject: Extending Defstruct
To: Common-Lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-Lisp@Sail.Stanford.EDU"
I am glad to see the revival of the discussion of defstruct. I brought
up this issue more than a year ago. At that time it got only one reply.
The defstruct facility would be much more useful to layered systems
builders if information about the defstruct definition was available.
In addition, you should be able to access and update a slot in a
structure via the slot name. Most implementations keep the necessary
information around anyway.
Simply being able to get the names of the accessor functions is not
sufficient. This will enable you to access the value of a slot by using
FUNCALL, but won't allow you to update the value of the slot because
funcall is not a valid place form.
I would like to see several functions added to the language:
STRUCTURE-SLOT structure slot [Function]
Returns the value of the slot in STRUCTURE specified by SLOT. STRUCTURE
is a defstruct instance and SLOT is a symbol. SETF may be used with
STRUCTURE-SLOT to modify a slot in a structure.
STRUCTURE-SLOT-NAMES structure-type [Function]
STRUCTURE-TYPE must be a type defined by DEFSTRUCT. This function
returns a list of slot names for structures of that type.
MAKE-STRUCTURE structure-type keyword-1 value-1 ... [Function]
Creates an instance of a structure. STRUCTURE-TYPE is the type of
structure to create. The rest of the arguments are the same as for the
default constructor function. If a slot is not initialised by a
slot-keyword, then the slot will be initialized with the default init
form specified in the defstruct.
STRUCTURE-OPTION structure-type option [Function]
STRUCTURE-TYPE must be a type defined by defstruct. OPTION must be a
defstruct option (e.g., :conc-name). This function returns the argument
that was given to that option if an argument was given in the call to
defstruct. Otherwise it returns the default value of that option.
For example, after the defstruct on page 312,
(structure-option 'astronaut :conc-name) ==> astro-
STRUCTURE-SLOT-OPTION structure-type slot option [Function]
STRUCTURE-TYPE must be a type defined by defstruct. SLOT is the name of
a slot in that defstruct. OPTION must be a defstruct slot option (:type
or :read-only). This function returns the argument that was given to
that option if an argument was given in the call to defstruct. Otherwise
it returns the default value of that option.
DEFSTRUCTP symbol [Function]
This function returns true if SYMBOL is the name of a defstruct type.
Kevin Gallagher
Gallagher@CS.UMass.EDU
∂06-Oct-87 2306 @RELAY.CS.NET:GALLAGHER@cs.umass.edu Defstruct and CLOS
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Oct 87 23:05:08 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ai03910; 7 Oct 87 1:24 EDT
Received: from cs.umass.edu by RELAY.CS.NET id dg12948; 7 Oct 87 1:22 EDT
Date: Tue, 6 Oct 87 19:00 EDT
From: Kevin Gallagher <GALLAGHER%cs.umass.edu@RELAY.CS.NET>
Subject: Defstruct and CLOS
To: Common-Lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-Lisp@Sail.Stanford.EDU"
> From: "Daniel L. Weinreb" <DLW@alderaan.scrc.symbolics.com>
>
> One idea that's been discussed that would do what you want, in fact do
> something more general, is to redefine structures in terms of
> object-oriented programming, if and after CLOS is accepted as part of
> Common Lisp. The basic idea is that CLOS would have a defined mechanism
> for talking about slots and their properties. I don't know whether
> this idea is still current; I suspect it's mainly on the back burner
> while the CLOS proposal itself is being finished.
One reason people use structures rather than ``objects'' is that there
is a significant overhead incurred by using objects. If defstruct were
subsumed into an object oriented standard there should be a way of
turning off all the power (and overhead) of the OOS. In particular, you
don't want the defstruct accessor functions to become generic functions.
Kevin Gallagher
∂06-Oct-87 2312 @RELAY.CS.NET:GALLAGHER@cs.umass.edu Extending Defstruct
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Oct 87 23:04:56 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ab03913; 7 Oct 87 1:24 EDT
Received: from cs.umass.edu by RELAY.CS.NET id de12948; 7 Oct 87 1:22 EDT
Date: Tue, 6 Oct 87 18:39 EDT
From: Kevin Gallagher <GALLAGHER%cs.umass.edu@RELAY.CS.NET>
Subject: Extending Defstruct
To: Common-Lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-Lisp@Sail.Stanford.EDU"
I am glad to see the revival of the discussion of defstruct. I brought
up this issue more than a year ago. At that time it got only one reply.
The defstruct facility would be much more useful to layered systems
builders if information about the defstruct definition was available.
In addition, you should be able to access and update a slot in a
structure via the slot name. Most implementations keep the necessary
information around anyway.
Simply being able to get the names of the accessor functions is not
sufficient. This will enable you to access the value of a slot by using
FUNCALL, but won't allow you to update the value of the slot because
funcall is not a valid place form.
I would like to see several functions added to the language:
STRUCTURE-SLOT structure slot [Function]
Returns the value of the slot in STRUCTURE specified by SLOT. STRUCTURE
is a defstruct instance and SLOT is a symbol. SETF may be used with
STRUCTURE-SLOT to modify a slot in a structure.
STRUCTURE-SLOT-NAMES structure-type [Function]
STRUCTURE-TYPE must be a type defined by DEFSTRUCT. This function
returns a list of slot names for structures of that type.
MAKE-STRUCTURE structure-type keyword-1 value-1 ... [Function]
Creates an instance of a structure. STRUCTURE-TYPE is the type of
structure to create. The rest of the arguments are the same as for the
default constructor function. If a slot is not initialised by a
slot-keyword, then the slot will be initialized with the default init
form specified in the defstruct.
STRUCTURE-OPTION structure-type option [Function]
STRUCTURE-TYPE must be a type defined by defstruct. OPTION must be a
defstruct option (e.g., :conc-name). This function returns the argument
that was given to that option if an argument was given in the call to
defstruct. Otherwise it returns the default value of that option.
For example, after the defstruct on page 312,
(structure-option 'astronaut :conc-name) ==> astro-
STRUCTURE-SLOT-OPTION structure-type slot option [Function]
STRUCTURE-TYPE must be a type defined by defstruct. SLOT is the name of
a slot in that defstruct. OPTION must be a defstruct slot option (:type
or :read-only). This function returns the argument that was given to
that option if an argument was given in the call to defstruct. Otherwise
it returns the default value of that option.
DEFSTRUCTP symbol [Function]
This function returns true if SYMBOL is the name of a defstruct type.
Kevin Gallagher
Gallagher@CS.UMass.EDU
∂06-Oct-87 2333 @RELAY.CS.NET:GALLAGHER@cs.umass.edu Defstruct and CLOS
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Oct 87 23:05:08 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ai03910; 7 Oct 87 1:24 EDT
Received: from cs.umass.edu by RELAY.CS.NET id dg12948; 7 Oct 87 1:22 EDT
Date: Tue, 6 Oct 87 19:00 EDT
From: Kevin Gallagher <GALLAGHER%cs.umass.edu@RELAY.CS.NET>
Subject: Defstruct and CLOS
To: Common-Lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-Lisp@Sail.Stanford.EDU"
> From: "Daniel L. Weinreb" <DLW@alderaan.scrc.symbolics.com>
>
> One idea that's been discussed that would do what you want, in fact do
> something more general, is to redefine structures in terms of
> object-oriented programming, if and after CLOS is accepted as part of
> Common Lisp. The basic idea is that CLOS would have a defined mechanism
> for talking about slots and their properties. I don't know whether
> this idea is still current; I suspect it's mainly on the back burner
> while the CLOS proposal itself is being finished.
One reason people use structures rather than ``objects'' is that there
is a significant overhead incurred by using objects. If defstruct were
subsumed into an object oriented standard there should be a way of
turning off all the power (and overhead) of the OOS. In particular, you
don't want the defstruct accessor functions to become generic functions.
Kevin Gallagher
∂07-Oct-87 0011 @RELAY.CS.NET:GALLAGHER@cs.umass.edu Defstruct and CLOS
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Oct 87 23:05:08 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ai03910; 7 Oct 87 1:24 EDT
Received: from cs.umass.edu by RELAY.CS.NET id dg12948; 7 Oct 87 1:22 EDT
Date: Tue, 6 Oct 87 19:00 EDT
From: Kevin Gallagher <GALLAGHER%cs.umass.edu@RELAY.CS.NET>
Subject: Defstruct and CLOS
To: Common-Lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-Lisp@Sail.Stanford.EDU"
> From: "Daniel L. Weinreb" <DLW@alderaan.scrc.symbolics.com>
>
> One idea that's been discussed that would do what you want, in fact do
> something more general, is to redefine structures in terms of
> object-oriented programming, if and after CLOS is accepted as part of
> Common Lisp. The basic idea is that CLOS would have a defined mechanism
> for talking about slots and their properties. I don't know whether
> this idea is still current; I suspect it's mainly on the back burner
> while the CLOS proposal itself is being finished.
One reason people use structures rather than ``objects'' is that there
is a significant overhead incurred by using objects. If defstruct were
subsumed into an object oriented standard there should be a way of
turning off all the power (and overhead) of the OOS. In particular, you
don't want the defstruct accessor functions to become generic functions.
Kevin Gallagher
∂08-Oct-87 1028 sandra%orion@cs.utah.edu compile-time actions & top-level forms (long)
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 10:28:02 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA18377; Thu, 8 Oct 87 11:27:55 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA11678; Thu, 8 Oct 87 11:27:49 MDT
Date: Thu, 8 Oct 87 11:27:49 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710081727.AA11678@orion.utah.edu>
Subject: compile-time actions & top-level forms (long)
To: common-lisp@sail.stanford.edu
The following is a rough proposal I've put together to try to get some
agreement on what the compile-time behavior of certain top-level
macros should be. I came up with many items on this list by noting
things that were "broken" or behaved surprisingly in some
implementations; KCL is certainly the worst offender in this respect.
The situations I've listed appear to be fairly standard programming
practices and I think we need to state explicitly somewhere that CL
supports them.
I have found that some implementations also have disturbing variations
from the behavior that is explicitly specified in CLtL regarding
evaluation of ordinary function calls appearing at the top level.
Some implementors have responded to my complaints by saying, in
effect, that if I don't like the default behavior they provide, I can
always explicitly wrap the offending form in an eval-when to get the
behavior I want. This just isn't good enough -- if everybody is free
to diverge from CLtL however they want, then I'd have to wrap *every*
top-level form with an eval-when to guarantee portability. Do we
really want to force that on unsuspecting users?
In many of these cases, the top-level form needs to store information
at compile time. I'm leaving open the possibility that the place where
the information is stored during compile-time processing might be
different than where it gets stored during normal load/eval processing.
My primary concern is that the information be available for use by the
compiler later on during the compilation of the same file.
A simple implementation technique (one which I've used to patch KCL,
for example) is to simply wrap the forms which store the information
in the macro expansion with an (eval-when (eval compile load) ...).
As a separate but related issue, I'd also like to see a DEF<something>
form defined to replace the magical compile-time behavior of the
package functions.
DEFTYPE. Type names defined via DEFTYPE should be recognized as valid
in subsequent type declarations.
(deftype small-int '(int 0 10))
(let ((x 0))
(declare (type small-int x))
....)
DEFMACRO. Macro definitions must be stored at compile time, so that
occurences of the macro later on in the file will be expanded
correctly.
(defmacro silly (x) `(car ,x))
... (silly foo) .... ; should compile as (car foo)
DEFUN. Nothing special is required here, although an implementation may
wish to store information about the lambda-list (etc.) for the purposes
of compile-time error checking.
DEFVAR, DEFPARAMETER. The compiler must recognize that the variables
have been proclaimed special. It is probably not a good idea to evaluate
the initial-value form.
(defvar *stack* (some-incredibly-hairy-function))
(let ((*stack* *stack*)) ; this should be a special binding.
....)
DEFCONSTANT. If this "normally" stores any information that is used by
the compiler (for example, to warn about assignment to or rebinding of
the variable), then this information should also be stored at compile time.
It's probably acceptable to evaluate the initial-value form in this case.
DEFSETF. The SETF method should be available during the expansion of
calls to SETF later on in the file. (Does anybody care about
DEFINE-SETF-METHOD and DEFINE-MODIFY-MACRO?)
(defsetf foo modify-foo)
(setf (foo x y) z)
DEFSTRUCT. The structure type name must be recognized as a valid type
name in declarations (as in the DEFTYPE example above). In addition,
further DEFSTRUCT definitions should be able to :include a structure
type defined earlier in the file being compiled. The functions which
DEFSTRUCT generates may or may not be available at compile time.
(defstruct person name age sex)
(defstruct (astronaut (:include person) (:conc-name astro-))
helmet-size
(favorite-beverage 'tang))
Questions & comments are welcome....
-Sandra
-------
∂08-Oct-87 1546 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 15:46:10 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 8 Oct 87 18:46:45-EDT
Date: Thu, 8 Oct 1987 18:46 EDT
Message-ID: <RAM.12340939736.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: compile-time actions & top-level forms (long)
In-reply-to: Msg of 8 Oct 1987 13:27-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
This obviously falls within the purview of the Compiler Cleanup
comittee, which unfortunately seems to be moribund. I agree with all
the expectation of compiler semantics that you mention, and my
proposal to the compiler cleanup comittee does have these properties.
As a separate but related issue, I'd also like to see a DEF<something>
form defined to replace the magical compile-time behavior of the
package functions.
The solution I propose is to require package manipulation forms to
appear at the beginning of the file. The package functions are only
special-cased when they appear in that position.
My proposal is accessible as <ram>cprop.txt on c.cs.cmu.edu. Anybody
who knows Lisp compilers and has a recent history of breathing is
encouraged to harrass the compiler comittee.
Rob
∂08-Oct-87 1639 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 15:46:10 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 8 Oct 87 18:46:45-EDT
Date: Thu, 8 Oct 1987 18:46 EDT
Message-ID: <RAM.12340939736.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: compile-time actions & top-level forms (long)
In-reply-to: Msg of 8 Oct 1987 13:27-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
This obviously falls within the purview of the Compiler Cleanup
comittee, which unfortunately seems to be moribund. I agree with all
the expectation of compiler semantics that you mention, and my
proposal to the compiler cleanup comittee does have these properties.
As a separate but related issue, I'd also like to see a DEF<something>
form defined to replace the magical compile-time behavior of the
package functions.
The solution I propose is to require package manipulation forms to
appear at the beginning of the file. The package functions are only
special-cased when they appear in that position.
My proposal is accessible as <ram>cprop.txt on c.cs.cmu.edu. Anybody
who knows Lisp compilers and has a recent history of breathing is
encouraged to harrass the compiler comittee.
Rob
∂08-Oct-87 1705 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 15:46:10 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 8 Oct 87 18:46:45-EDT
Date: Thu, 8 Oct 1987 18:46 EDT
Message-ID: <RAM.12340939736.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: compile-time actions & top-level forms (long)
In-reply-to: Msg of 8 Oct 1987 13:27-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
This obviously falls within the purview of the Compiler Cleanup
comittee, which unfortunately seems to be moribund. I agree with all
the expectation of compiler semantics that you mention, and my
proposal to the compiler cleanup comittee does have these properties.
As a separate but related issue, I'd also like to see a DEF<something>
form defined to replace the magical compile-time behavior of the
package functions.
The solution I propose is to require package manipulation forms to
appear at the beginning of the file. The package functions are only
special-cased when they appear in that position.
My proposal is accessible as <ram>cprop.txt on c.cs.cmu.edu. Anybody
who knows Lisp compilers and has a recent history of breathing is
encouraged to harrass the compiler comittee.
Rob
∂08-Oct-87 1734 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 15:46:10 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 8 Oct 87 18:46:45-EDT
Date: Thu, 8 Oct 1987 18:46 EDT
Message-ID: <RAM.12340939736.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: compile-time actions & top-level forms (long)
In-reply-to: Msg of 8 Oct 1987 13:27-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
This obviously falls within the purview of the Compiler Cleanup
comittee, which unfortunately seems to be moribund. I agree with all
the expectation of compiler semantics that you mention, and my
proposal to the compiler cleanup comittee does have these properties.
As a separate but related issue, I'd also like to see a DEF<something>
form defined to replace the magical compile-time behavior of the
package functions.
The solution I propose is to require package manipulation forms to
appear at the beginning of the file. The package functions are only
special-cased when they appear in that position.
My proposal is accessible as <ram>cprop.txt on c.cs.cmu.edu. Anybody
who knows Lisp compilers and has a recent history of breathing is
encouraged to harrass the compiler comittee.
Rob
∂08-Oct-87 1744 jbarnett@nrtc.northrop.com I need help
Received: from NRTC.NORTHROP.COM by SAIL.STANFORD.EDU with TCP; 8 Oct 87 17:42:39 PDT
Received: by nrtc.nrtc.northrop.com id aa03397; 8 Oct 87 17:42 PDT
Date: Thu, 8 Oct 87 17:34:11 PDT
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
To: common-lisp@sail.stanford.edu
Subject: I need help
I am currently trying to design and implement a high level protocol to lash
together a bunch of programs running on SYMBOLICS and SUNS. The protocol is
a generalization of the EVAL protocol used by the distributed DCLOCKS shell.
Unfortunately, the SUN documentation available to me doesn't discuss what is
available in terms of stack groups, processes, network code, etc.
I need pointers to more detailed SUN documentation, or better yet,
a knowledgable individual to talk to. Any suggestions of volunters would
be much appreciated. Thanks in advance for any help or sympathy.
Jeff Barnett
∂08-Oct-87 1759 Moon@STONY-BROOK.SCRC.Symbolics.COM compile-time actions & top-level forms (long)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Oct 87 17:59:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 252027; Thu 8-Oct-87 20:28:27 EDT
Date: Thu, 8 Oct 87 20:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: compile-time actions & top-level forms (long)
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8710081727.AA11678@orion.utah.edu>
Message-ID: <871008202812.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 8 Oct 87 11:27:49 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
....
As a separate but related issue, I'd also like to see a DEF<something>
form defined to replace the magical compile-time behavior of the
package functions.
I don't know or remember why the Common Lisp committee would not accept
DEFPACKAGE. It seems simple and obvious to me. In Symbolics Common Lisp,
it accepts the same arguments as MAKE-PACKAGE, except for the obvious syntactic
differences between a macro and a function, namely that nothing is evaluated
and that a keyword and its associated arguments are enclosed in parentheses
(like defstruct-options). In SCL, the arguments to MAKE-PACKAGE are
(NAME &KEY NICKNAMES PREFIX-NAME USE SHADOW EXPORT IMPORT SHADOWING-IMPORT
IMPORT-FROM relative-names relative-names-for-me SIZE EXTERNAL-ONLY
new-symbol-function hash-inherited-symbols invisible colon-mode
prefix-intern-function include)
The arguments in lower case are features that probably don't exist in
straight Common Lisp.
I agree with all your other suggestions.
∂08-Oct-87 1811 jbarnett@nrtc.northrop.com I need help
Received: from NRTC.NORTHROP.COM by SAIL.STANFORD.EDU with TCP; 8 Oct 87 17:42:39 PDT
Received: by nrtc.nrtc.northrop.com id aa03397; 8 Oct 87 17:42 PDT
Date: Thu, 8 Oct 87 17:34:11 PDT
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
To: common-lisp@sail.stanford.edu
Subject: I need help
I am currently trying to design and implement a high level protocol to lash
together a bunch of programs running on SYMBOLICS and SUNS. The protocol is
a generalization of the EVAL protocol used by the distributed DCLOCKS shell.
Unfortunately, the SUN documentation available to me doesn't discuss what is
available in terms of stack groups, processes, network code, etc.
I need pointers to more detailed SUN documentation, or better yet,
a knowledgable individual to talk to. Any suggestions of volunters would
be much appreciated. Thanks in advance for any help or sympathy.
Jeff Barnett
∂08-Oct-87 1817 jbarnett@nrtc.northrop.com I need help
Received: from NRTC.NORTHROP.COM by SAIL.STANFORD.EDU with TCP; 8 Oct 87 17:42:39 PDT
Received: by nrtc.nrtc.northrop.com id aa03397; 8 Oct 87 17:42 PDT
Date: Thu, 8 Oct 87 17:34:11 PDT
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
To: common-lisp@sail.stanford.edu
Subject: I need help
I am currently trying to design and implement a high level protocol to lash
together a bunch of programs running on SYMBOLICS and SUNS. The protocol is
a generalization of the EVAL protocol used by the distributed DCLOCKS shell.
Unfortunately, the SUN documentation available to me doesn't discuss what is
available in terms of stack groups, processes, network code, etc.
I need pointers to more detailed SUN documentation, or better yet,
a knowledgable individual to talk to. Any suggestions of volunters would
be much appreciated. Thanks in advance for any help or sympathy.
Jeff Barnett
∂08-Oct-87 2337 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Oct 87 15:46:10 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 8 Oct 87 18:46:45-EDT
Date: Thu, 8 Oct 1987 18:46 EDT
Message-ID: <RAM.12340939736.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: compile-time actions & top-level forms (long)
In-reply-to: Msg of 8 Oct 1987 13:27-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
This obviously falls within the purview of the Compiler Cleanup
comittee, which unfortunately seems to be moribund. I agree with all
the expectation of compiler semantics that you mention, and my
proposal to the compiler cleanup comittee does have these properties.
As a separate but related issue, I'd also like to see a DEF<something>
form defined to replace the magical compile-time behavior of the
package functions.
The solution I propose is to require package manipulation forms to
appear at the beginning of the file. The package functions are only
special-cased when they appear in that position.
My proposal is accessible as <ram>cprop.txt on c.cs.cmu.edu. Anybody
who knows Lisp compilers and has a recent history of breathing is
encouraged to harrass the compiler comittee.
Rob
∂09-Oct-87 0741 RWK@YUKON.SCRC.Symbolics.COM compile-time actions & top-level forms (long)
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 9 Oct 87 07:41:41 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 274377; Fri 9-Oct-87 09:43:11 EDT
Date: Fri, 9 Oct 87 09:43 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: compile-time actions & top-level forms (long)
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8710081727.AA11678@orion.utah.edu>
Message-ID: <871009094342.8.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 8 Oct 87 11:27:49 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
This is pretty good. I have a general comment, and a few specifics.
General comment: Those forms which affect the compilation environment
should not be *required* to leave that effect behind when the compilation
is finished. That is, it should be legal for a compiler, when finished
compiling a file or set of files, to leave your environment exactly as
it was before starting.
The tricky part is "set of files"; there is a concept of scoping possible
for a single compilation over multiple files. This is particularly useful
if you defer warnings about undefined functions that are defined in later
files. But as far as the language standard is concerned, I think it is
best if the compilation is not defined to affect the environment, and you
should be required to load the file before compiling the next if you want
macro definitions to be visible in the next file, portably.
Systems which are used for weeks at a time without booting shouldn't be
polluted by compiling, say, a file of macros with incompatible changes.
Specific comments: [I agree 200% with everything I've deleted.]
DEFVAR, DEFPARAMETER. The compiler must recognize that the variables
have been proclaimed special. It is probably not a good idea to evaluate
the initial-value form.
It should be definitely illegal to evaluate it at load time.
DEFCONSTANT. If this "normally" stores any information that is used by
the compiler (for example, to warn about assignment to or rebinding of
the variable), then this information should also be stored at compile time.
It's probably acceptable to evaluate the initial-value form in this case.
Yes, this should be *required* to be evaluatable at compile time.
If there were such a thing as "evaluatable-p", it could be deferred
if not, but if the compiler is going to make use of this, it has
to know it can evaluate it.
DEFSETF. The SETF method should be available during the expansion of
calls to SETF later on in the file. (Does anybody care about
DEFINE-SETF-METHOD and DEFINE-MODIFY-MACRO?)
Yes, both of those as well.
DEFSTRUCT. The structure type name must be recognized as a valid type
name in declarations (as in the DEFTYPE example above). In addition,
further DEFSTRUCT definitions should be able to :include a structure
type defined earlier in the file being compiled. The functions which
DEFSTRUCT generates may or may not be available at compile time.
But the accessors must be made available to SETF.
∂09-Oct-87 0836 RAM@C.CS.CMU.EDU compile-time actions & top-level forms (long)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Oct 87 08:36:48 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Fri 9 Oct 87 11:37:18-EDT
Date: Fri, 9 Oct 1987 11:37 EDT
Message-ID: <RAM.12341123699.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
Cc: common-lisp@SAIL.STANFORD.EDU,
Sandra J Loosemore <sandra%orion@CS.UTAH.EDU>
Subject: compile-time actions & top-level forms (long)
In-reply-to: Msg of 9 Oct 1987 09:43-EDT from Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>
Date: Friday, 9 October 1987 09:43-EDT
From: Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>
To: Sandra J Loosemore <sandra%orion at cs.utah.edu>
cc: common-lisp at sail.stanford.edu
Re: compile-time actions & top-level forms (long)
Date: Thu, 8 Oct 87 11:27:49 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
This is pretty good. I have a general comment, and a few specifics.
General comment: Those forms which affect the compilation
environment should not be *required* to leave that effect behind
when the compilation is finished. [...] I think it is best if the
compilation is not defined to affect the environment,
I agree with this.
[...] and you should be required to load the file before compiling
the next if you want macro definitions to be visible in the next
file, portably.
I don't exactly agree with this. I don't think that you should assume
that the COMPILE-FILE environment necessarily has anything in common
with the environment seen by the user REP loop. This means that doing
a LOAD may not make definitions available to a following COMPILE-FILE.
This is what REQUIRE is for.
[I also agree with the other remarks made by RWK...]
Rob
∂09-Oct-87 0951 sandra%orion@cs.utah.edu REQUIRE
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 9 Oct 87 09:51:01 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA01872; Fri, 9 Oct 87 10:50:37 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA16553; Fri, 9 Oct 87 10:50:32 MDT
Date: Fri, 9 Oct 87 10:50:32 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710091650.AA16553@orion.utah.edu>
Subject: REQUIRE
To: Ram@c.cs.cmu.edu
Cc: "Robert W. Kerns" <RWK@scrc-yukon.arpa>, common-lisp@sail.stanford.edu,
Sandra J Loosemore <sandra%orion@cs.utah.edu>
In-Reply-To: Ram@C.CS.CMU.EDU, Fri, 9 Oct 1987 11:37 EDT
From: Ram@C.CS.CMU.EDU
This means that doing a LOAD may not make definitions available to a
following COMPILE-FILE. This is what REQUIRE is for.
Well, maybe that's what REQUIRE was intended to be used for, but I'm
afraid it hasn't turned out that way in practice. Portability problems
with PROVIDE and REQUIRE are currently #2 on my list, after problems
with top-level forms. In fact, it appears that many (most?) CL
implementations insist on treating PROVIDE and REQUIRE specially when
they appear as top-level forms. The other problem is that
implementation-specific way that REQUIRE looks for the files to load if
you don't provide a specific pathname. I'm currently trying to get the
same bits of code to run under 4 different CL implementations (and
two different operating systems with incompatible filename conventions,
no less) and I've got the compiled files from each implementation living
in separate subdirectories....
If it were up to me, I'd like to see a variable named something like
*REQUIRE-PATHNAME-DEFAULTS*, which specifies where REQUIRE should look
for modules if you don't give an explicit pathname.
-Sandra
-------
∂09-Oct-87 1233 cutting.pa@Xerox.COM Re: *REQUIRE-PATHNAME-DEFAULTS*
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87 12:33:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 12:23:28 PDT
Date: 9 Oct 87 12:23 PDT
From: cutting.pa@Xerox.COM
Subject: Re: *REQUIRE-PATHNAME-DEFAULTS*
In-reply-to: sandra%orion@cs.utah.edu's message of Fri, 9 Oct 87
10:50:32 MDT
To: sandra%orion@cs.utah.edu
cc: common-lisp@sail.stanford.edu
Message-ID: <871009-122328-1356@Xerox>
Date: Fri, 9 Oct 87 10:50:32 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
If it were up to me, I'd like to see a variable named something like
*REQUIRE-PATHNAME-DEFAULTS*, which specifies where REQUIRE should look
for modules if you don't give an explicit pathname.
Yes! To flesh out the specification:
*REQUIRE-PATHNAME-DEFAULTS* [Variable]
A pathname or list of pathnames searched in order by REQUIRE when no
pathname is explicitly specified.
By allowing lists of pathnames we allow multiple "library" directories
as well as multiple file types. For example, a user could push his own
directory on to the standard path as follows:
(setq *require-pathname-defaults*
(list*
(make-pathname :directory "~/lisp" :type "lisp")
(make-pathname :directory "~/lisp" :type "fasl")
*require-pathname-defaults*))
∂09-Oct-87 1338 cutting.pa@Xerox.COM Re: *REQUIRE-PATHNAME-DEFAULTS*
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87 12:33:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 12:23:28 PDT
Date: 9 Oct 87 12:23 PDT
From: cutting.pa@Xerox.COM
Subject: Re: *REQUIRE-PATHNAME-DEFAULTS*
In-reply-to: sandra%orion@cs.utah.edu's message of Fri, 9 Oct 87
10:50:32 MDT
To: sandra%orion@cs.utah.edu
cc: common-lisp@sail.stanford.edu
Message-ID: <871009-122328-1356@Xerox>
Date: Fri, 9 Oct 87 10:50:32 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
If it were up to me, I'd like to see a variable named something like
*REQUIRE-PATHNAME-DEFAULTS*, which specifies where REQUIRE should look
for modules if you don't give an explicit pathname.
Yes! To flesh out the specification:
*REQUIRE-PATHNAME-DEFAULTS* [Variable]
A pathname or list of pathnames searched in order by REQUIRE when no
pathname is explicitly specified.
By allowing lists of pathnames we allow multiple "library" directories
as well as multiple file types. For example, a user could push his own
directory on to the standard path as follows:
(setq *require-pathname-defaults*
(list*
(make-pathname :directory "~/lisp" :type "lisp")
(make-pathname :directory "~/lisp" :type "fasl")
*require-pathname-defaults*))
∂11-Oct-87 1802 Marion.StudentIM@MIT-Multics.ARPA Mailing List
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 11 Oct 87 18:02:10 PDT
Delivery-Date: 11 Oct 87 20:42 EDT
Delivery-By: Network_Server.Daemon@MIT-Multics.ARPA
Date: Sun, 11 Oct 87 20:36 EDT
From: Marion@MIT-Multics.ARPA
Subject: Mailing List
Message-ID: <871012003626.851916@MIT-Multics.ARPA>
Resent-Date: 11 Oct 87 20:58 EDT
Resent-From: Marion@MIT-Multics.ARPA
Resent-To: COMMON-LISP@SAIL.STANFORD.EDU
Resent-Message-ID: <871012005851.152580@MIT-Multics.ARPA>
Please add me to your mailing list. Thank you.
∂11-Oct-87 1858 pyrnj!pyramid!bein@RUTGERS.EDU ...
Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 11 Oct 87 18:58:00 PDT
Received: by RUTGERS.EDU (5.54/1.14) with UUCP
id AA19722; Sun, 11 Oct 87 20:47:19 EDT
Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424)
id AA21802; Sun, 11 Oct 87 15:44:26 PDT
Received: by pyrnova.pyramid.COM (5.52/OSx4.0b-870424)
id AA11888; Sun, 11 Oct 87 15:46:49 PDT
Date: 11 Oct 1987 15:41-PDT
From: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Subject: ...
To: common-lisp@sail.stanford.edu@RUTGERS.EDU
Message-Id: <560990513/bein@pyrnova>
Do functions created by DEFTYPE, DEFINE-SETF-METHOD and
DEFSETF have the same restriction as DEFMACRO (page 145 CLtL)
does about where the function body is effectively defined,
i.e. would it be legal to take DEFTYPE, DEFINE-SETF-METHOD
and DEFSETF forms and evaluate them as if <form> (wherever it
appears) is (EVAL '<form>) ...
--David
∂11-Oct-87 1921 RAM@c.cs.cmu.edu ... [compile-time lexical environment]
Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 11 Oct 87 19:21:03 PDT
Received: by RUTGERS.EDU (5.54/1.14)
id AA23606; Sun, 11 Oct 87 22:21:05 EDT
Received: ID <RAM@C.CS.CMU.EDU>; Sun 11 Oct 87 22:17:21-EDT
Date: Sun, 11 Oct 1987 22:17 EDT
Message-Id: <RAM.12341764500.BABYL@>
Sender: RAM@λλ
From: Ram@c.cs.cmu.edu
To: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Cc: common-lisp%sail.stanford.edu@RUTGERS.EDU
Subject: ... [compile-time lexical environment]
In-Reply-To: Msg of 11 Oct 1987 18:41-EDT from David Bein <pyrnj!pyramid!bein at RUTGERS.EDU>
If a form is implcitly evaluated at compile time, then it cannot
access the lexical environment, since the environment doesn't exist
until run-time. Given this, the only alternative to requiring that
the null environment be used is stating that the environment is
undefined. I see no advantage in the latter, and no reason to resolve
the problem in a different way than DEFMACRO currently does.
Rob
∂11-Oct-87 2051 Pavel.pa@Xerox.COM Re: the lexical environment for DEFTYPE, DEFINE-SETF-METHOD and
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Oct 87 20:50:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 OCT 87 20:50:06 PDT
Date: Sun, 11 Oct 87 20:49:48 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: the lexical environment for DEFTYPE, DEFINE-SETF-METHOD and
DEFSETF
In-reply-to: <560990513/bein@pyrnova>
To: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Cc: common-lisp@sail.stanford.edu
Message-ID: <871011-205006-2922@Xerox>
Date: 11 Oct 87 15:41 PDT
From: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Do functions created by DEFTYPE, DEFINE-SETF-METHOD and
DEFSETF have the same restriction as DEFMACRO (page 145 CLtL)
does about where the function body is effectively defined,
i.e. would it be legal to take DEFTYPE, DEFINE-SETF-METHOD
and DEFSETF forms and evaluate them as if <form> (wherever it
appears) is (EVAL '<form>) ...
If I understand your question correctly, you are referring to the
sentence in the description of DEFMACRO that states that the body of a
DEFMACRO is evaluated in the null lexical environment. This restriction
was put in with the thought that it was necessary in order for the
compiler to be able to macroexpand forms without evaluating the
surrounding code to create a lexical environment.
This argument, however, is bogus, since it is the lexical environment of
the DEFMACRO, not that of the macro-call, that is important. If a
DEFMACRO appears in a non-null lexical environment, the compiler is not
obliged to notice it at all (aside from compiling it correctly). That
is, later forms in the same file may not depend upon that macro having
been installed. (On the other hand, if you then load that file, the
compilation of later files \may/ count on the macro being present.)
Regardless of all this, the restriction is still a part of the language
and so, for consistency's sake, given the understanding everyone has
about the correctness of Sandra's top-level form proposal, the same
restriction should indeed apply to the three kinds of forms you
mentioned: DEFTYPE, DEFINE-SETF-METHOD and DEFSETF. More succinctly,
the answer to your question is yes.
On the other hand, the language would probably be better served by
removing the restriction on DEFMACRO instead. Perhaps someday I'll get
around to proposing this to the cleanup committee...
Pavel
∂12-Oct-87 0908 RAM@C.CS.CMU.EDU the lexical environment for DEFTYPE, DEFINE-SETF-METHOD and
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 09:08:38 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 12 Oct 87 11:56:47-EDT
Date: Mon, 12 Oct 1987 11:56 EDT
Message-ID: <RAM.12341913648.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: Pavel.pa@XEROX.COM
Cc: common-lisp@SAIL.STANFORD.EDU,
David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Subject: the lexical environment for DEFTYPE, DEFINE-SETF-METHOD and
In-reply-to: Msg of 11 Oct 1987 23:49-EDT from Pavel.pa at Xerox.COM
Date: Sunday, 11 October 1987 23:49-EDT
From: Pavel.pa at Xerox.COM
To: David Bein <pyrnj!pyramid!bein at RUTGERS.EDU>
cc: common-lisp at sail.stanford.edu
Re: the lexical environment for DEFTYPE, DEFINE-SETF-METHOD and
DEFSETF
[...] the description of DEFMACRO that states that the body of a
DEFMACRO is evaluated in the null lexical environment. This restriction
was put in with the thought that it was necessary in order for the
compiler to be able to macroexpand forms without evaluating the
surrounding code to create a lexical environment.
This argument, however, is bogus, since it is the lexical environment of
the DEFMACRO, not that of the macro-call, that is important. If a
DEFMACRO appears in a non-null lexical environment, the compiler is not
obliged to notice it at all (aside from compiling it correctly). That
is, later forms in the same file may not depend upon that macro having
been installed.
If I believed in your proposed semantics for DEFMACRO, then I would
buy this argument, but I don't. It seems to me to be a bizzarre
suggestion that the semantics of an operation should depend on whether
the environment is null or not. I think that the only reason that
anyone buys this at all is that Lisp compilers have traditionally
magically special-cased forms that "appear at top-level", whatever
that means.
I think that there is a pretty convincing argument that the whole
concept of a "top-level form" is inappropriate in a lexically scoped
Lisp. In my proposal for Common Lisp compilation (really evaluation)
semantics, I define things in a way that is consistent with general
usage, but makes no use of the concept "top level".
Rob
∂12-Oct-87 1103 RAM@C.CS.CMU.EDU REQUIRE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 09:58:10 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 12 Oct 87 12:58:23-EDT
Date: Mon, 12 Oct 1987 12:58 EDT
Message-ID: <RAM.12341924875.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU, "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
Subject: REQUIRE
In-reply-to: Msg of 9 Oct 1987 12:50-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
Date: Friday, 9 October 1987 12:50-EDT
From: sandra%orion at cs.utah.edu (Sandra J Loosemore)
To: Ram at c.cs.cmu.edu
Re: REQUIRE
From: Ram@C.CS.CMU.EDU
This means that doing a LOAD may not make definitions available to a
following COMPILE-FILE. This is what REQUIRE is for.
Well, maybe that's what REQUIRE was intended to be used for, but I'm
afraid it hasn't turned out that way in practice. Portability problems
with PROVIDE and REQUIRE are currently #2 on my list, after problems
with top-level forms. In fact, it appears that many (most?) CL
implementations insist on treating PROVIDE and REQUIRE specially when
they appear as top-level forms.
This may be just a mental block on my part, but I always used to
wonder why anyone would use PROVIDE/REQUIRE at all. More recently I
came to the conclusion that their reason for existence was to state
compile-time dependencies, i.e. loading macro packages at compile
time. If you believe this, then it is obvious that the compiler must
evaluate REQUIRE at compile time.
But on reading the manual just now, I don't see any support for this
theory that REQUIRE is a mechanism for dealing with compile-time
dependencies.
Probably anyone who either:
a] Has strong beliefs about what PROVIDE/REQUIRE should do, or
b] has a good solution to the compile-time dependency problem
should speak up.
It does seem to be useful to have some syntax attached to the code
file that the compiler can recognize as an explicit manipulation of
its environment.
The other problem is that implementation-specific way that REQUIRE
looks for the files to load if you don't provide a specific
pathname. [...] If it were up to me, I'd like to see a variable
named something like *REQUIRE-PATHNAME-DEFAULTS*, which specifies
where REQUIRE should look for modules if you don't give an
explicit pathname.
Having some standard mechanism for specifying a library search-list
seems reasonable. We have this capability, but implement it using our
"logical device" mechanism. Note that having simple default
interpretation for REQUIRE without a pathname doesn't prevent
implementations from providing alternate interpretations as long as
the simple version still works.
Rob
∂12-Oct-87 1102 pyrnj!pyramid!bein@RUTGERS.EDU defmacro environment again..
Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 10:18:50 PDT
Received: by RUTGERS.EDU (5.54/1.14) with UUCP
id AA22162; Mon, 12 Oct 87 13:21:57 EDT
Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424)
id AA07026; Mon, 12 Oct 87 10:17:55 PDT
Received: by pyrnova.pyramid.COM (5.52/OSx4.0b-870424)
id AA17592; Mon, 12 Oct 87 10:20:15 PDT
Date: 12 Oct 1987 10:01-PDT
From: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Subject: defmacro environment again..
To: ram@c.cs.cmu.edu, pavel.pa@xerox.com
Cc: common-lisp@sail.stanford.edu@RUTGERS.EDU
Message-Id: <561056467/bein@pyrnova>
I'll rephrase the question. Suppose you have the following
in some file:
(let ((a <some-value>))
(defun a-getter () a)
(defun a-setter (value) (setq a value)))
It is fairly clear what the compiler should do with this, namely
build a lexical environment when the file is loaded and
create two compiled closures using that environment which define
a-getter and a-setter.
Now suppose we have the following:
(let ((a <some-value>))
(defmacro hack () `(list 1 2 3 ',a))
(defun a-setter (value) (setq a value)))
Is the macro HACK allowed to refer to the lexical value of A
which was apparent when the macro function for HACK was
created (loaded)? (I know this is difficult if the macro is used
in the compiler's environment since the compiler does not
have the lexical environment around yet..) ...
If I read the manual correctly, it is saying that HACK may not
refer to the lexical environment it was defined in. So
my question is, should DEFTYPE,DEFINE-SETF-METHOD and
DEFSETF (complicated version) be the same way?
This is really separate from the &environment arg which
a macro function could use in the runtime environment
to call macroexpand with.
--David
∂12-Oct-87 1105 RAM@c.cs.cmu.edu defmacro environment again..
Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 10:56:54 PDT
Received: by RUTGERS.EDU (5.54/1.14)
id AA23288; Mon, 12 Oct 87 14:00:07 EDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 12 Oct 87 13:56:05-EDT
Date: Mon, 12 Oct 1987 13:55 EDT
Message-Id: <RAM.12341935392.BABYL@>
Sender: RAM@λλ
From: Ram@c.cs.cmu.edu
To: David Bein <pyramid!bein@sun.com>
Cc: common-lisp%sail.stanford.edu@RUTGERS.EDU, pavel.pa@xerox.com
Subject: defmacro environment again..
In-Reply-To: Msg of 12 Oct 1987 13:01-EDT from David Bein <pyramid!bein at Sun.COM>
Everyone seems to agree that it would be most consistent with the rest
of Common Lisp for the bodies of DEFTYPE, DEFINE-SETF-METHOD, ... to
be evaluated in the null environment. There was only disagreement
over whether these forms would do something else in the best of all
possible Lisp dialects.
Rob
∂12-Oct-87 1121 pyrnj!pyramid!bein@RUTGERS.EDU defmacro environment again..
Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 10:18:50 PDT
Received: by RUTGERS.EDU (5.54/1.14) with UUCP
id AA22162; Mon, 12 Oct 87 13:21:57 EDT
Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424)
id AA07026; Mon, 12 Oct 87 10:17:55 PDT
Received: by pyrnova.pyramid.COM (5.52/OSx4.0b-870424)
id AA17592; Mon, 12 Oct 87 10:20:15 PDT
Date: 12 Oct 1987 10:01-PDT
From: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Subject: defmacro environment again..
To: ram@c.cs.cmu.edu, pavel.pa@xerox.com
Cc: common-lisp@sail.stanford.edu@RUTGERS.EDU
Message-Id: <561056467/bein@pyrnova>
I'll rephrase the question. Suppose you have the following
in some file:
(let ((a <some-value>))
(defun a-getter () a)
(defun a-setter (value) (setq a value)))
It is fairly clear what the compiler should do with this, namely
build a lexical environment when the file is loaded and
create two compiled closures using that environment which define
a-getter and a-setter.
Now suppose we have the following:
(let ((a <some-value>))
(defmacro hack () `(list 1 2 3 ',a))
(defun a-setter (value) (setq a value)))
Is the macro HACK allowed to refer to the lexical value of A
which was apparent when the macro function for HACK was
created (loaded)? (I know this is difficult if the macro is used
in the compiler's environment since the compiler does not
have the lexical environment around yet..) ...
If I read the manual correctly, it is saying that HACK may not
refer to the lexical environment it was defined in. So
my question is, should DEFTYPE,DEFINE-SETF-METHOD and
DEFSETF (complicated version) be the same way?
This is really separate from the &environment arg which
a macro function could use in the runtime environment
to call macroexpand with.
--David
∂12-Oct-87 1352 RAM@C.CS.CMU.EDU REQUIRE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 09:58:10 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 12 Oct 87 12:58:23-EDT
Date: Mon, 12 Oct 1987 12:58 EDT
Message-ID: <RAM.12341924875.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU, "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
Subject: REQUIRE
In-reply-to: Msg of 9 Oct 1987 12:50-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)
Date: Friday, 9 October 1987 12:50-EDT
From: sandra%orion at cs.utah.edu (Sandra J Loosemore)
To: Ram at c.cs.cmu.edu
Re: REQUIRE
From: Ram@C.CS.CMU.EDU
This means that doing a LOAD may not make definitions available to a
following COMPILE-FILE. This is what REQUIRE is for.
Well, maybe that's what REQUIRE was intended to be used for, but I'm
afraid it hasn't turned out that way in practice. Portability problems
with PROVIDE and REQUIRE are currently #2 on my list, after problems
with top-level forms. In fact, it appears that many (most?) CL
implementations insist on treating PROVIDE and REQUIRE specially when
they appear as top-level forms.
This may be just a mental block on my part, but I always used to
wonder why anyone would use PROVIDE/REQUIRE at all. More recently I
came to the conclusion that their reason for existence was to state
compile-time dependencies, i.e. loading macro packages at compile
time. If you believe this, then it is obvious that the compiler must
evaluate REQUIRE at compile time.
But on reading the manual just now, I don't see any support for this
theory that REQUIRE is a mechanism for dealing with compile-time
dependencies.
Probably anyone who either:
a] Has strong beliefs about what PROVIDE/REQUIRE should do, or
b] has a good solution to the compile-time dependency problem
should speak up.
It does seem to be useful to have some syntax attached to the code
file that the compiler can recognize as an explicit manipulation of
its environment.
The other problem is that implementation-specific way that REQUIRE
looks for the files to load if you don't provide a specific
pathname. [...] If it were up to me, I'd like to see a variable
named something like *REQUIRE-PATHNAME-DEFAULTS*, which specifies
where REQUIRE should look for modules if you don't give an
explicit pathname.
Having some standard mechanism for specifying a library search-list
seems reasonable. We have this capability, but implement it using our
"logical device" mechanism. Note that having simple default
interpretation for REQUIRE without a pathname doesn't prevent
implementations from providing alternate interpretations as long as
the simple version still works.
Rob
∂12-Oct-87 1916 Pavel.pa@Xerox.COM Re: the lexical environment for DEFTYPE, DEFINE-SETF-METHOD and
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Oct 87 12:44:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 OCT 87 11:57:17 PDT
Date: Mon, 12 Oct 87 11:57:06 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: the lexical environment for DEFTYPE, DEFINE-SETF-METHOD and
In-reply-to: <RAM.12341913648.BABYL@>
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <871012-115717-3651@Xerox>
Date: Mon, 12 Oct 87 11:56 EDT
From: Ram@C.CS.CMU.EDU
If I believed in your proposed semantics for DEFMACRO, then I would
buy this argument, but I don't. It seems to me to be a bizzarre
suggestion that the semantics of an operation should depend on whether
the environment is null or not. I think that the only reason that
anyone buys this at all is that Lisp compilers have traditionally
magically special-cased forms that "appear at top-level", whatever
that means.
I think that there is a pretty convincing argument that the whole
concept of a "top-level form" is inappropriate in a lexically scoped
Lisp. In my proposal for Common Lisp compilation (really evaluation)
semantics, I define things in a way that is consistent with general
usage, but makes no use of the concept "top level".
If I remember your proposal correctly (it's been a while since I read
it), you insist that the compiler ALWAYS be able to evaluate the body of
a DEFMACRO. I claim that this is overly restrictive. I can well
imagine wanting to use a lexical variable as an "own" variable for
maintaining state across expansions of a particular macro. Such
variables might be used for allowing functionality like the :include
feature of DEFSTRUCT, for keeping statistics, etc. Your semantics would
not allow this.
I have no trouble with requiring the compiler to notice macro
definitions and to make use of them when it can. I also have no trouble
with there being a class of such definitions that cannot be made use of
at compilation time.
Pavel
∂12-Oct-87 2121 @Score.Stanford.EDU:diamant%hpfclp@hplabs.HP.COM Re: REQUIRE
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Oct 87 21:21:45 PDT
Received: from hplabs.HP.COM (hplabs.hpl.hp.com.#Internet) by SCORE.STANFORD.EDU with TCP; Mon 12 Oct 87 21:17:28-PDT
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Mon, 12 Oct 87 17:57:45 PDT
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Mon, 12 Oct 87 18:50:03 mdt
Received: from hpfcjrd.HP.COM by hpfclp.HP.COM; Mon, 12 Oct 87 18:49:44 mdt
Received: from hpfcjrd by hpfcjrd.HP.COM; Mon, 12 Oct 87 18:49:52 mdt
Return-Path: <diamant@hpfcjrd>
To: common-lisp@sail.stanford.edu
Subject: Re: REQUIRE
X-Answer: 42
X-Mailer: mh6.5 + ivomh
Date: Mon, 12 Oct 87 18:49:50 MDT
Message-Id: <29520.561084590@hpfcjrd>
From: John Diamant <diamant%hpfclp@hplabs.HP.COM>
I have strong beliefs about what PROVIDE/REQUIRE should do (at least what
their purpose is in the language).
They are a necessary mechanism for loading needed modules exactly once.
LOAD is inadequate for loading complete subsystems as it becomes very
difficult to make sure you only load something once. I do believe it
should occur at compile-time since many dependencies are at compile-time,
not just during execution. But even if this only covered execution-time
dependencies, the purpose for REQUIRE would be clear. If I access
functions in a module written by someone else, then I need to bring that
module into the system. If I have several optional parts of my system,
then each of my parts may need to make sure that the module is loaded. If
they all used LOAD, multiple copies would be loaded, thus wasting space (at
least in many implementations it would). With REQUIRE, I avoid that, and
also have a way of registering a module for public consumption.
John Diamant
Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM
∂13-Oct-87 1149 kclmail@rascal.ics.utexas.edu KCL Mailing List
Received: from NGP.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 13 Oct 87 11:48:59 PDT
Posted-Date: Tue, 13 Oct 87 12:15:32 CDT
Received: by ngp.utexas.edu (5.51/5.51)
id AA04440; Tue, 13 Oct 87 12:15:47 CDT
Date: Tue, 13 Oct 87 12:15:32 CDT
From: kclmail@rascal.ics.utexas.edu (Bob Boyer)
Message-Id: <8710131715.AA24859@rascal.ics.utexas.edu>
Received: by rascal.ics.utexas.edu (3.2/4.22)
id AA24859; Tue, 13 Oct 87 12:15:32 CDT
To: common-lisp@sail.stanford.edu
Subject: KCL Mailing List
An electronic mailing list for news about Kyoto Common Lisp has been
established. To have your name placed on this list, send a message to
the Arpanet/Internet address:
kcl-request@rascal.ics.utexas.edu
To post an item to those on the list, send a note to Arpanet/Internet
address:
kcl@rascal.ics.utexas.edu
The authors of KCL, Yuasa and Hagiya, are on the list.
A discouragingly high percentage of those in electronically remote
corners of the U.S.A. or in foreign countries who receive this message
and who send a message to kcl-request asking to join the list will be
inaccessible from rascal.ics.utexas.edu because of a variety of network
problems. If you do not regularly send mail to and receive mail from
several Arpanet sites, please include in any request to kcl-request a
paper mail address to which I can mail my regrets over your apparent
inaccessibility if necessary.
Messages to kcl@rascal.ics.utexas.edu will be archived in the file
/pub/kcl-mail-archive, accessible by ftping into rascal.ics.utexas.edu as
user ftp, any password. In the same place is the file kcl.broadcast,
which contains information about obtaining without fee the Kyoto
Common Lisp system, including sources, after the appropriate license
procedures have been completed.
∂15-Oct-87 2118 peck@Sun.COM The IDENTITY function and multiple args
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 15 Oct 87 21:17:38 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
id AA27648; Thu, 15 Oct 87 21:13:14 PDT
Received: from denali.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA20740; Thu, 15 Oct 87 21:17:16 PDT
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA04480; Thu, 15 Oct 87 21:17:33 PDT
Message-Id: <8710160417.AA04480@denali.sun.com>
To: common-lisp@sail.stanford.edu
Subject: The IDENTITY function and multiple args
Date: Thu, 15 Oct 87 21:17:31 -0700
From: peck@Sun.COM
Is there a fundamental reason why #'IDENTITY and #'VALUES should be different?
VALUES seems like a much safer function to use for a "default" function,
since it will nicely consume any number of args and return them, which
is the same behavior that the improverished IDENTITY does for a single arg.
Why encourage programmers to make fragile programs by documenting "IDENTITY"?
∂16-Oct-87 0738 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM The IDENTITY function and multiple args
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Oct 87 07:38:26 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 133712; Fri 16-Oct-87 09:50:40 EDT
Date: Fri, 16 Oct 87 09:51 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: The IDENTITY function and multiple args
To: peck@Sun.COM, common-lisp@sail.stanford.edu
In-Reply-To: <8710160417.AA04480@denali.sun.com>
Message-ID: <871016095157.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Thu, 15 Oct 87 21:17:31 -0700
From: peck@Sun.COM
Is there a fundamental reason why #'IDENTITY and #'VALUES should be different?
VALUES seems like a much safer function to use for a "default" function,
since it will nicely consume any number of args and return them, which
is the same behavior that the improverished IDENTITY does for a single arg.
Why encourage programmers to make fragile programs by documenting "IDENTITY"?
Two reasons I see:
1, Intent: If the intent is to return one value based on one argument,
then IDENTITY is the correct function to use. It "is an error" to pass
it more or less than one argument, and some implementations "signal an
error." If the intent is to accept multiple values and pass them
through, then VALUES is the correct function to use. I don't consider
VALUES and "safer" or IDENTITY introducing "fragility". On the
contrary, I would claim that failure to program the intent will make the
program less safe and more fragile.
2, Efficiency (linguistically, this is a weak argument): some
(many?) implementations optimize the one return-value case. This makes
multiple values less efficient.
∂16-Oct-87 0815 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM The IDENTITY function and multiple args
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Oct 87 07:38:26 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 133712; Fri 16-Oct-87 09:50:40 EDT
Date: Fri, 16 Oct 87 09:51 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: The IDENTITY function and multiple args
To: peck@Sun.COM, common-lisp@sail.stanford.edu
In-Reply-To: <8710160417.AA04480@denali.sun.com>
Message-ID: <871016095157.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Thu, 15 Oct 87 21:17:31 -0700
From: peck@Sun.COM
Is there a fundamental reason why #'IDENTITY and #'VALUES should be different?
VALUES seems like a much safer function to use for a "default" function,
since it will nicely consume any number of args and return them, which
is the same behavior that the improverished IDENTITY does for a single arg.
Why encourage programmers to make fragile programs by documenting "IDENTITY"?
Two reasons I see:
1, Intent: If the intent is to return one value based on one argument,
then IDENTITY is the correct function to use. It "is an error" to pass
it more or less than one argument, and some implementations "signal an
error." If the intent is to accept multiple values and pass them
through, then VALUES is the correct function to use. I don't consider
VALUES and "safer" or IDENTITY introducing "fragility". On the
contrary, I would claim that failure to program the intent will make the
program less safe and more fragile.
2, Efficiency (linguistically, this is a weak argument): some
(many?) implementations optimize the one return-value case. This makes
multiple values less efficient.
∂16-Oct-87 0825 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM The IDENTITY function and multiple args
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Oct 87 07:38:26 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 133712; Fri 16-Oct-87 09:50:40 EDT
Date: Fri, 16 Oct 87 09:51 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: The IDENTITY function and multiple args
To: peck@Sun.COM, common-lisp@sail.stanford.edu
In-Reply-To: <8710160417.AA04480@denali.sun.com>
Message-ID: <871016095157.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Thu, 15 Oct 87 21:17:31 -0700
From: peck@Sun.COM
Is there a fundamental reason why #'IDENTITY and #'VALUES should be different?
VALUES seems like a much safer function to use for a "default" function,
since it will nicely consume any number of args and return them, which
is the same behavior that the improverished IDENTITY does for a single arg.
Why encourage programmers to make fragile programs by documenting "IDENTITY"?
Two reasons I see:
1, Intent: If the intent is to return one value based on one argument,
then IDENTITY is the correct function to use. It "is an error" to pass
it more or less than one argument, and some implementations "signal an
error." If the intent is to accept multiple values and pass them
through, then VALUES is the correct function to use. I don't consider
VALUES and "safer" or IDENTITY introducing "fragility". On the
contrary, I would claim that failure to program the intent will make the
program less safe and more fragile.
2, Efficiency (linguistically, this is a weak argument): some
(many?) implementations optimize the one return-value case. This makes
multiple values less efficient.
∂16-Oct-87 0832 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM with-open-stream and with-open-file
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Oct 87 08:32:13 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 133767; Fri 16-Oct-87 11:32:33 EDT
Date: Fri, 16 Oct 87 11:33 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: with-open-stream and with-open-file
To: common-lisp@sail.stanford.edu
Message-ID: <871016113352.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
CLtL says that the stream (file) scoped by with-open-stream
(with-open-file) is closed when the form is exited, independent of
exit-reason. I would like people to consider the following allowance:
that if the stream variable is NIL during the close operation, then the
stream (file) is not closed. Thus
(with-open-stream (stream constructor)
(prog1 stream (setq stream nil)))
would evaluate to an open stream. The strict reading of CLtL says that
the stream should be closed and the stream, not the variable, should
be considered to have dynamic extent. (I'd quote, except my book is
packed.) I don't like the word "considered" as it could be interpreted
to legitimize not closing the stream.
Personally, I have found the above technique (setting the stream
variable to nil and returning the stream) as quite useful; the Symbolics
implementation already implementing the relaxation. I ask that the
language be clarified.
Also, the (prog1 stream (setq stream nil)) is a cliche which can also be
written as (shiftf stream nil). For many months I have not liked either
of those forms; the way they look, not what they do. Unfortunately, the
best form I've been able to think of is (grab-and-clear stream) and I
don't like that very much either.
∂16-Oct-87 1059 Pavel.pa@Xerox.COM Re: with-open-stream and with-open-file
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Oct 87 10:58:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 OCT 87 10:56:29 PDT
Date: Fri, 16 Oct 87 10:56:21 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: with-open-stream and with-open-file
In-reply-to: <871016113352.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
To: common-lisp@sail.stanford.edu
Message-ID: <871016-105629-3613@Xerox>
Date: Fri, 16 Oct 87 11:33 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
CLtL says that the stream (file) scoped by with-open-stream
(with-open-file) is closed when the form is exited, independent of
exit-reason. I would like people to consider the following allowance:
that if the stream variable is NIL during the close operation, then the
stream (file) is not closed. Thus
(with-open-stream (stream constructor)
(prog1 stream (setq stream nil)))
would evaluate to an open stream.
[More language supporting the above as an idiom.]
Surely I'm misunderstanding you. Why use the above form instead of
simply `constructor'? It must be that you mean to do more stuff before
the prog1, perhaps to "set up" the stream and/or some other structures
concerned with it. The idea would be to have the implicit
unwind-protect around those set-up forms and then be able to leave the
unwind-protect with the stream still open. Have I properly understood
your intent?
If so, then I must say that I would find the form you describe far less
clear than the equivalent explicit unwind-protect. In general, I
dislike forms that pass information to invisible parts by the setting of
a lexical variable. The information path is just too hidden.
Pavel
∂16-Oct-87 1124 Pavel.pa@Xerox.COM Re: with-open-stream and with-open-file
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Oct 87 10:58:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 OCT 87 10:56:29 PDT
Date: Fri, 16 Oct 87 10:56:21 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: with-open-stream and with-open-file
In-reply-to: <871016113352.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
To: common-lisp@sail.stanford.edu
Message-ID: <871016-105629-3613@Xerox>
Date: Fri, 16 Oct 87 11:33 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
CLtL says that the stream (file) scoped by with-open-stream
(with-open-file) is closed when the form is exited, independent of
exit-reason. I would like people to consider the following allowance:
that if the stream variable is NIL during the close operation, then the
stream (file) is not closed. Thus
(with-open-stream (stream constructor)
(prog1 stream (setq stream nil)))
would evaluate to an open stream.
[More language supporting the above as an idiom.]
Surely I'm misunderstanding you. Why use the above form instead of
simply `constructor'? It must be that you mean to do more stuff before
the prog1, perhaps to "set up" the stream and/or some other structures
concerned with it. The idea would be to have the implicit
unwind-protect around those set-up forms and then be able to leave the
unwind-protect with the stream still open. Have I properly understood
your intent?
If so, then I must say that I would find the form you describe far less
clear than the equivalent explicit unwind-protect. In general, I
dislike forms that pass information to invisible parts by the setting of
a lexical variable. The information path is just too hidden.
Pavel
∂16-Oct-87 1311 DCP@YUKON.SCRC.Symbolics.COM Re: with-open-stream and with-open-file
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 87 13:11:21 PDT
Received: from SWAN.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 277966; Fri 16-Oct-87 16:11:56 EDT
Date: Fri, 16 Oct 87 16:12 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: with-open-stream and with-open-file
To: Pavel.pa@Xerox.COM, common-lisp@sail.stanford.edu
In-Reply-To: <871016-105629-3613@Xerox>
Message-ID: <19871016201200.1.DCP@SWAN.SCRC.Symbolics.COM>
Date: Fri, 16 Oct 87 10:56:21 PDT
From: Pavel.pa@Xerox.COM
[deleted]
Surely I'm misunderstanding you. Why use the above form instead of
simply `constructor'?
In my example, there is no reason...
It must be that you mean to do more stuff before
the prog1, perhaps to "set up" the stream and/or some other structures
concerned with it.
... and indeed this is what I typically use it for. I checked a few of
my cases, and what is >really< going on, for me, is in the internals of
constructing a stream and is something like
(defun open (pathname &rest open-options)
(with-open-stream (stream (construct-file-stream))
...process-options...
(shiftf stream nil)))
The idea would be to have the implicit
unwind-protect around those set-up forms and then be able to leave the
unwind-protect with the stream still open. Have I properly understood
your intent?
Yes.
If so, then I must say that I would find the form you describe far less
clear than the equivalent explicit unwind-protect. In general, I
dislike forms that pass information to invisible parts by the setting of
a lexical variable. The information path is just too hidden.
That's a good point which I'll have to think about. Five minutes'
reflection, clearly not enough, says:
- with-open-thing neatly packages the unwind-protect and the abort
cleanup.
- with-open-thing requires the programmer to remember only one form:
the with-open-thing form. This observation is quite weak; convention
would dictate that there would be a corresponding open-thing form
(e.g., with-open-serial-stream/open-serial-stream). It might be,
however, that the with-open-thing is an external symbol and
open-thing is internal.
The first observation will probably cause me to continue my current
practices, though at a higher level of awareness.
Whatever consensus we come to, the language should be clarified and
faulty implementations corrected so that the goal of writing portable
programs isn't diminished.
∂19-Oct-87 0846 Steve.Handerson@spice.cs.cmu.edu Compiler-let
Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Oct 87 08:46:37 PDT
Date: 19 Oct 1987 11:32-EDT
From: Steve.Handerson@SPICE.CS.CMU.EDU
To: common-lisp@sail.stanford.edu
Subject: Compiler-let
Message-Id: <561655978/skh@SPICE.CS.CMU.EDU>
I apologize if this has been brought up and settled previously.
Compiler-let limits its usefulness by stating only that it
special-binds during evaluation.
Where lazy macroexpansion is used in the evaluator,
there's a clear and useless difference between compile-time and
runtime behavior; the bindings aren't there any more.
Instead, CL should loudly proclaim that whatever compiler-let binds
will be special-bound for all macroexpansions occuring within.
Only evaluators not based on compilation need be changed,
and I think it's worth the effort
(especially if the evaluators in question aren't too hairy).
It would be nice if existing implementations were updated
in this matter, but I guess everyone has to agree first.
-- Steve
∂19-Oct-87 1051 gls@Think.COM [boyer@rascal.ics.utexas.edu: CLTL]
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 19 Oct 87 10:51:29 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Mon, 19 Oct 87 13:51:21 EDT
Received: by kali.think.com; Mon, 19 Oct 87 13:51:37 EDT
Date: Mon, 19 Oct 87 13:51:37 EDT
From: gls@Think.COM
Message-Id: <8710191751.AA27708@kali.think.com>
To: common-lisp@sail.stanford.edu
Subject: [boyer@rascal.ics.utexas.edu: CLTL]
We can all feel good about a comment like this:
Date: Mon, 12 Oct 87 09:06:54 CDT
From: boyer@rascal.ics.utexas.edu (Bob Boyer)
I want to express to you my great gratitude for your having put
together CLTL. J Moore and I have recently finished converting our
theorem-prover from a Franz/Zetalisp/Maclisp/PSL version to Common
Lisp. The converted code now runs with absolutely no operating system
or dialect dependencies under Symbolics Common Lisp, Kyoto Common
Lisp, and Lucid Common Lisp. And I half suspect that it might still
run on those systems a decade from now. How wonderful to be relieved
of the dread that every few months a new "release" of whatever Lisp I
was using would break my code!
The only incompatibility between the three Lisps we encountered was
about the meanings of the "put in seven extremely random user
interface commands", which we just decided to avoid completely.
This last paragraph seemed quite timely, apropos of the current
discussion about REQUIRE.
--Guy
∂24-Oct-87 0130 @RELAY.CS.NET:CORK@cs.umass.edu RE: Extending DEFSTRUCT
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 24 Oct 87 01:30:01 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac18609; 24 Oct 87 2:18 EDT
Received: from cs.umass.edu by RELAY.CS.NET id bf09392; 24 Oct 87 2:11 EDT
Date: Fri, 23 Oct 87 12:26 EDT
From: "Dan Corkill, COINS, Umass (413)545-0156" <CORK%cs.umass.edu@RELAY.CS.NET>
Subject: RE: Extending DEFSTRUCT
To: Common-Lisp@SAIL.STANFORD.EDU
X-VMS-To: IN%"Common-Lisp@SAIL.Stanford.Edu"
Kevin Gallagher has twice proposed what I believe is a well-reasoned and
much needed extension to defstruct-defined structures. About a year ago
his first proposal received one favorable response on the list and died.
His most recent reposting (in response to the recent discussion of
defstruct) has received no responses.
[The proposed extensions were:
STRUCTURE-SLOT structure slot {a valid SETF form} [Function]
STRUCTURE-SLOT-NAMES structure-type [Function]
MAKE-STRUCTURE structure-type keyword-1 value-1 ... [Function]
STRUCTURE-OPTION structure-type option [Function]
STRUCTURE-SLOT-OPTION structure-type slot option [Function]
DEFSTRUCTP symbol [Function]
]
I would like to believe that the lack of responses to Kevin's extensions
(or any further discussion of defstruct and structures) indicated an
implicit endorsement of a useful proposal. Anyone who builds portable
tools, layered systems, or extensible languages that rely on defstruct-
defined structures needs these capabilities. They are relatively easy for
an implementer to provide, they are impossible for a user to write in an
implementation independent manner, they do not violate the storage
abstraction provided by defstruct, and they elevate structures to the same
level of ``official'' support for interrogatives as arrays. (I can ask for
the dimensions of an array but not the slot-names of a structure?) I
heartily endorse his proposal.
In fact, I would add two more EXTENSIONS that I have found frustratingly
absent from the CL specifications.
---------------------------------------------------------------------------
Add'l extension 1:
There is no way in the type system to detect if an object is a structure
whose structure name has been added to the CL data-type system (i.e.,
defined with no :TYPE option). The following would provide this ability:
STRUCTUREP object [Function]
Returns true if object is a structure whose structure name has been added
to the CL data-type system; nil otherwise.
---------------------------------------------------------------------------
Add'l extension 2:
I often use defstruct print functions to print structures in a palatable
format for human eyes. I also want them printed using the normal #S()
notation when writing them to a database file. The following is a tempting
way of writing such print functions:
(defun EMPLOYEE-DEFSTRUCT-PRINTER (employee stream print-depth)
(declare (ignore print-depth))
(cond
;; Less-than-pretty printing requested ::
((and (not *print-pretty*) *print-escape*)
(prin1 employee))
;; Pretty printing requested ::
(t
(format stream "{Employee: ~A}" (employee-name employee)))))
Of course, this will NOT work because there is no way of disabling the
employee print function during the printing performed by prin1. Instead, I
am forced to duplicate the printing of the default #S() format myself. (I
might be tempted to write a generic print-structure-in-default-format
function, but of course I would need the extensions proposed by Gallagher
to do that!) So instead of prin1, I must write:
(format stream
"#S(EMPLOYEE :SOCIAL-SECURITY-NUMBER ~S ~
:NAME ~S :HOURLY-RATE ~S ...)"
(employee-social-security-number employee)
(employee-name employee)
(employee-hourly-rate employee) ...))
Explicitly naming each slot in the structure (and remembering to change the
printer if a slot is added or deleted from the defstruct definition).
Ugh!! The abstraction provided by defstruct has been lost (as well as
whatever efficient default printing of structures has been provided by the
implementers).
A simple parameter *INHIBIT-DEFSTRUCT-PRINTERS* to control whether or not
printing uses or ignores the defstruct print function would save the day!
Voila:
(defun EMPLOYEE-DEFSTRUCT-PRINTER (employee stream print-depth)
(declare (ignore print-depth))
(cond
;; Less-than-pretty printing requested ::
((and (not *print-pretty*) *print-escape*)
(let ((*inhibit-defstruct-printers* t))
(prin1 stream employee)))
;; Pretty printing requested ::
(t
(format stream "{Employee: ~A}" (employee-name employee)))))
---------------------------------------------------------------------------
Structures have become such an important component of CL. It's unfortunate
that the lack of a few simple extensions seriously hamper using them.
-- Dan Corkill
cork@cs.umass.edu
∂24-Oct-87 1224 TOURETZKY@C.CS.CMU.EDU extending DEFSTRUCT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Oct 87 12:24:05 PDT
Received: ID <TOURETZKY@C.CS.CMU.EDU>; Sat 24 Oct 87 15:16:09-EDT
Date: Sat 24 Oct 87 15:16:08-EDT
From: Dave.Touretzky@C.CS.CMU.EDU
Subject: extending DEFSTRUCT
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12345095715.31.TOURETZKY@C.CS.CMU.EDU>
I support the proposal of Gallagher and Corkill, with one modification:
Instead of *INHIBIT-DEFSTRUCT-PRINTERS*, there should be a variable called
*PRINT-STRUCTURE* that is analagous to *PRINT-ARRAY*.
When *PRINT-STRUCTURE* is T:
defstructs with their own print functions will use them
defstructs without prnt functions will print in the #S() notation
When *PRINT-STRUCTURE* in NIL:
defstructs with their own print functions will use them
defstructs without their own print function will print in the #<> notation
When *PRINT-STRUCTURE* is :FORCE
all defstructs print in #S() notation
-- Dave
-------
∂24-Oct-87 2036 pyrnj!pyramid!bein@RUTGERS.EDU macrolet/flet/labels
Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 24 Oct 87 20:35:59 PDT
Received: by RUTGERS.EDU (5.54/1.14) with UUCP
id AA16558; Sat, 24 Oct 87 23:39:14 EDT
Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424)
id AA23234; Sat, 24 Oct 87 19:01:02 PDT
Received: by pyrnova.pyramid.COM (5.52/OSx4.0b-870424)
id AA27898; Sat, 24 Oct 87 19:02:43 PDT
Date: 24 Oct 1987 18:57-PDT
From: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Subject: macrolet/flet/labels
To: common-lisp@sail.stanford.edu@RUTGERS.EDU
Message-Id: <562125428/bein@pyrnova>
What is the current consensus about using a name
within a macrolet/flet/labels construct which
is a special form? I am cleaning things up this
way and it occurred to me that things could go
either way.
I think the only really ugly one is QUOTE since most
compilers seem to treat that specially in all kinds of
places. Another equally nasty one would be FUNCTION.
--David
∂25-Oct-87 0624 Rick.Busdiecker@H.GP.CS.CMU.EDU extending DEFSTRUCT
Received: from H.GP.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Oct 87 06:24:36 PST
Date: 25 Oct 1987 08:47-EST
From: Rick.Busdiecker@H.GP.CS.CMU.EDU
To: Dave.Touretzky@C.CS.CMU.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: extending DEFSTRUCT
Reply-To: Rick.Busdiecker@cs.cmu.edu
Message-Id: <562168063/rfb@H.GP.CS.CMU.EDU>
I also support the proposed extensions to structure handling.
Date: Sat 24 Oct 87 15:16:08-EDT
From: Dave.Touretzky@C.CS.CMU.EDU
When *PRINT-STRUCTURE* in NIL:
defstructs with their own print functions will use them
defstructs without their own print function will print in the #<> notation
Is there really a standard for #<> notation? If so, what is it and
where is it defined? If not, perhaps we should define a default #<>
notation such as #<name-of-structure-type>.
Rick
∂25-Oct-87 0939 norvig%cogsci.Berkeley.EDU@ucbvax.Berkeley.EDU extending DEFSTRUCT
Received: from [128.32.130.5] by SAIL.STANFORD.EDU with TCP; 25 Oct 87 09:39:29 PST
Received: by cogsci.berkeley.edu (5.58/1.26)
id AA20167; Sun, 25 Oct 87 09:43:08 PST
Date: Sun, 25 Oct 87 09:43:08 PST
From: norvig%cogsci.Berkeley.EDU@ucbvax.Berkeley.EDU (Peter Norvig)
Message-Id: <8710251743.AA20167@cogsci.berkeley.edu>
To: common-lisp@sail.stanford.edu
Subject: extending DEFSTRUCT
I agree with Touretzky's proposal, except I would add:
When *PRINT-STRUCTURE* is a non-nil list:
defstructs whose types are members of the list use their own print function
defstructs whose types are not in the list use #S()
I think the membership test should be TYPEP, and that :INCLUDEd types
inherit the print function dynamically (with possibility of over-ride,
of course).
I personally prefer to use a macro DEFSTRUCT-PRINT-FUNCTION so that
I can define the print function separately from the DEFSTRUCT itself,
but I wouldn't go so far as to make that part of CL; rather, let's:
define a GET-PRINT-FUNCTION function (with a SETF form)
which returns the print function associated with a type.
∂25-Oct-87 1620 Pavel.pa@Xerox.COM Re: macrolet/flet/labels
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Oct 87 16:20:49 PST
Received: from Salvador.ms by ArpaGateway.ms ; 25 OCT 87 16:21:30 PST
Date: Sun, 25 Oct 87 15:44:22 PST
From: Pavel.pa@Xerox.COM
Subject: Re: macrolet/flet/labels
In-reply-to: <562125428/bein@pyrnova>
To: common-lisp@sail.stanford.edu
Message-ID: <871025-162130-1009@Xerox>
Date: 24 Oct 87 18:57 PDT
From: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
What is the current consensus about using a name
within a macrolet/flet/labels construct which
is a special form? I am cleaning things up this
way and it occurred to me that things could go
either way.
I am of the opinion that the names of the special forms are really
reserved words and that you cannot redefine them even lexically. Thus,
none of the names of special forms can be used as the defined-name in
flet, labels, or macrolet.
I can't imagine a case in which this could be anything but extremely
confusing to a program reader nor can I think of any reason why it might
be useful.
Pavel
∂25-Oct-87 1830 RWK@YUKON.SCRC.Symbolics.COM extending DEFSTRUCT
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 25 Oct 87 18:30:43 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 281872; Sun 25-Oct-87 21:31:32 EST
Date: Sun, 25 Oct 87 21:31 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: extending DEFSTRUCT
To: Rick.Busdiecker@cs.cmu.edu
cc: Dave.Touretzky@C.CS.CMU.EDU, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <562168063/rfb@H.GP.CS.CMU.EDU>
Message-ID: <19871026023112.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: 25 Oct 1987 08:47-EST
From: Rick.Busdiecker@H.GP.CS.CMU.EDU
I also support the proposed extensions to structure handling.
Date: Sat 24 Oct 87 15:16:08-EDT
From: Dave.Touretzky@C.CS.CMU.EDU
When *PRINT-STRUCTURE* in NIL:
I think a slightly better name is *PRINT-STRUCTURE-CONTENTS*.
(We've had this for a couple years).
Most of us find this has to be NIL in order not to be innundated
with useless internal details of the structures we look at.
(The #<...> representations are designed to provide what information
you need at a glance).
Generally, CL fails to distinguish between PRINT/READ as communication
between programs (in which case, you either want to bind all the flags
to standard, known values, or ignored totally), and communication with
the user or programmer, in which case you want the flags set for maximum
usability. #S syntax is clearly an example where utility for programs
was chosen over usability for programmers.
defstructs with their own print functions will use them
defstructs without their own print function will print in the #<> notation
Is there really a standard for #<> notation? If so, what is it and
where is it defined? If not, perhaps we should define a default #<>
notation such as #<name-of-structure-type>.
The standard is that it signals an error (see pg 360 of CLtL).
What CLtL doesn't say, but should, is that:
1) The #< should be balanced with a >.
2) There are certain recommended higher conventions to be followed:
a) The type should be given first. This is not necessarily
what TYPE-OF will return, but it should be descriptive
and non-confusing to the user. (This means it should
probably be a type acceptable to TYPEP, of which this object
is a member). The structure type name is the default.
b) Named objects should, where possible, follow their type
with their name.
c) Other descriptive information may be included, in a user-determined
(but brief) format.
d) Where it is desirable to distinguish different instances of
the same type of object, which may otherwise print the same,
the last thing printed before the closing ">" should be a
unique-ID. (On our system we use the octal address by default).
This should generally be omitted when there is no difficulty
distinguishing objects on sight (for example, objects with
unique names).
As you can see, these are conventions designed to make things easier
for the programmer looking at these objects while debugging, and
not something that some program or other rigid-thinking entity
will look at.
∂26-Oct-87 0731 cerys%RTS-12.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: extending DEFSTRUCT
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 07:30:53 PST
Received: from RTS-12.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 Oct 87 10:27-EST
Message-Id: <2771248902-3508558@RTS-12>
Sender: cerys@RTS-12
Date: Mon, 26 Oct 87 10:21:42 EST
From: "Daniel L. Cerys" <Cerys@XX.LCS.MIT.EDU>
To: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics.COM>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Re: extending DEFSTRUCT
In-Reply-To: Msg of Sun, 25 Oct 87 21:31 EST from Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
> When *PRINT-STRUCTURE* in NIL:
> I think a slightly better name is *PRINT-STRUCTURE-CONTENTS*.
> (We've had this for a couple years).
I agree on the utility of this variable, but not on its name. Since
*PRINT-ARRAY* determines whether the contents of arrays are printed, a
variable named *PRINT-STRUCTURE* should do the same for structures.
Using *PRINT-STRUCTURE-CONTENTS* wouldn't be as clear.
∂26-Oct-87 0856 SWM@SAPSUCKER.SCRC.Symbolics.COM Re: macrolet/flet/labels
Received: from [128.81.41.223] by SAIL.STANFORD.EDU with TCP; 26 Oct 87 08:55:34 PST
Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 175095; Mon 26-Oct-87 11:57:40 EST
Date: Mon, 26 Oct 87 11:55 EST
From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
Subject: Re: macrolet/flet/labels
To: Pavel.pa@Xerox.COM, common-lisp@sail.stanford.edu
In-Reply-To: <871025-162130-1009@Xerox>
Message-ID: <19871026165544.1.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM>
Date: Sun, 25 Oct 87 15:44:22 PST
From: Pavel.pa@Xerox.COM
Date: 24 Oct 87 18:57 PDT
From: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
What is the current consensus about using a name
within a macrolet/flet/labels construct which
is a special form? I am cleaning things up this
way and it occurred to me that things could go
either way.
I am of the opinion that the names of the special forms are really
reserved words and that you cannot redefine them even lexically. Thus,
none of the names of special forms can be used as the defined-name in
flet, labels, or macrolet.
I can't imagine a case in which this could be anything but extremely
confusing to a program reader nor can I think of any reason why it might
be useful.
We subscribe to your notions here. Our compiler warns you that you will
probably lose when you FLET/LABEL/MACROLET a special form.
∂26-Oct-87 0934 Moon@ALLEGHENY.SCRC.Symbolics.COM Re: extending DEFSTRUCT
Received: from [128.81.41.45] by SAIL.STANFORD.EDU with TCP; 26 Oct 87 09:34:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 69577; Mon 26-Oct-87 12:11:28 EST
Date: Mon, 26 Oct 87 12:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: extending DEFSTRUCT
To: Daniel L. Cerys <Cerys@XX.LCS.MIT.EDU>
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <2771248902-3508558@RTS-12>
Message-ID: <19871026171117.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 26 Oct 87 10:21:42 EST
From: "Daniel L. Cerys" <Cerys@XX.LCS.MIT.EDU>
> Kerns:
> When *PRINT-STRUCTURE* in NIL:
> I think a slightly better name is *PRINT-STRUCTURE-CONTENTS*.
> (We've had this for a couple years).
I agree on the utility of this variable, but not on its name. Since
*PRINT-ARRAY* determines whether the contents of arrays are printed, a
variable named *PRINT-STRUCTURE* should do the same for structures.
Using *PRINT-STRUCTURE-CONTENTS* wouldn't be as clear.
Don't you think that what that really indicates is that the name
*PRINT-ARRAY* was poorly chosen and is not as clear? If you look
through the list of printer flags on CLtL pp.370-373, *print-array*
is the only one that doesn't connote very well what it does, to my
ear. It's as if someone thought it was more important to make all
the names exactly two words long.
∂26-Oct-87 1050 extending DEFSTRUCT
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 10:50:31 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 Oct 87 13:27-EST
Received: from JASPER.Palladian.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 65230; 26 Oct 87 13:16:01-EST
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 12227; 26 Oct 87 12:27:26-EST
Date: Mon, 26 Oct 87 12:25 EST
From: Don Morrison <dfm@JASPER.Palladian.COM>
Subject: extending DEFSTRUCT
To: Rick.Busdiecker@cs.cmu.edu
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <562168063/rfb@H.GP.CS.CMU.EDU>
Message-ID: <871026122502.1.DFM@WHITBY.Palladian.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>
Date: 25 Oct 1987 08:47-EST
From: Rick.Busdiecker@H.GP.CS.CMU.EDU
Is there really a standard for #<> notation? If so, what is it and
where is it defined? If not, perhaps we should define a default #<>
notation such as #<name-of-structure-type>.
If you do, you probably should make it #<name-of-structure-type NNN> where NNN is an integer (decimal?) such
that two eq structures always have the same number, and two not eq structures don't. I believe this corresponds
pretty closely to current practice for those implementations that do support such a beast. The major
difference, I believe, is that often NNN is currently an address that can change over time; it would probably be
cleaner for eq structures to always print the same, no matter how manner GCs have intervened. Since the hash or
whatever it is you'd stick there would only need to be computed if you're printing the thing, I suspect it
wouldn't add any serious overhead to structures that's not already there to support eq hash tables.
∂26-Oct-87 1252 kessler%cons@cs.utah.edu 1988 LISP & FUNCTIONAL PROGRAMMING - CALL FOR PAPERS
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 26 Oct 87 12:52:24 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA17779; Mon, 26 Oct 87 13:52:35 MST
Received: by cons.UTAH.EDU (4.30/4.40.2)
id AA03833; Mon, 26 Oct 87 13:52:20 mst
Date: Mon, 26 Oct 87 13:52:20 mst
From: kessler%cons@cs.utah.edu (Robert R. Kessler)
Message-Id: <8710262052.AA03833@cons.UTAH.EDU>
To: common-lisp@sail.stanford.edu
Subject: 1988 LISP & FUNCTIONAL PROGRAMMING - CALL FOR PAPERS
CALL FOR PAPERS
1988 ACM Conference on
LISP AND FUNCTIONAL PROGRAMMING
Snowbird, Utah, July 25-27, 1988
The 1988 ACM Conference on LISP and Functional Programming is the
fifth in a series of biennial conferences devoted to the theory,
design, and implementation of programming languages and systems
that support symbolic computation. The conference is jointly
sponsored by ACM SIGPLAN, SIGACT, and SIGART. Papers presented
at the conference must include new ideas or experimental results
that have not been previously published. The conference program
is not limited to topics discussed in previous conferences in the
series; authors are strongly encouraged to submit papers that in-
troduce important new topics that are relevant to functional pro-
gramming and symbolic computation. The major topics that have
been addressed at previous conferences include:
1) programming language concepts and facilities
2) implementation methods
3) machine architectures
4) semantic foundations
5) programming logics
6) program development environments
7) applications of symbolic computation Authors are invited to
submit 11 copies of a technical summary of a prospective confer-
ence paper to the program committee chairman. The length of the
summary should not exceed 3,000 words (10 pages double-spaced or
typeset 10-point on 16-point spacing). Since the committee ex-
pects to receive a large number of submissions, the summary
should be organized so that it is easily understood. It is im-
portant for the summary to identify what has been accomplished,
explain why it is significant, and compare it with previous work.
Submissions must be received by Jan 22, 1988. They should in-
clude a return postal address and an electronic mail address if
it is available. Authors will be notified of the acceptance or
rejection of their papers by March 11, 1988. Full versions of
the accepted papers must be received in camera-ready form by
April 22, 1988. Authors of accepted papers will be required to
sign ACM copyright release forms. Proceedings will be distribut-
ed at the conference and will later be available for purchase
from the ACM. The conference site at Snowbird, Utah is a resort
located in the rugged Wasatch mountain range approximately 35
miles from Salt Lake City. Summer activities include hiking,
climbing, swimming, tennis, and wildflower photography.
Program Committee Chairman Program Committee
Robert (Corky) Cartwright Harold Abelson, MIT
Attn: LFP 88 Richard Bird, Oxford University
Rice University Luca Cardelli, DEC Systems Res. Ctr.
Department of Computer Science Robert Cartwright, Rice University
P. O. Box 1892 Richard Gabriel, Lucid Inc.
Houston, TX 77251-1892 Christopher Haynes, Indiana University
(713) 527-4834 Gerard Huet, INRIA Rocquencourt
cork@rice.edu Gilles Kahn, INRIA Sophia Antipolis
David Moon, Symbolics Inc.
Guy Steele, Thinking Machines Corp.
Carolyn Talcott, Stanford University
General Chairman Local Arrangements Chairman
Jerome Chailloux Robert Kessler
INRIA University of Utah
Domaine de Voluceau-Rocquencourt Department of Computer Science
B.P. 105 3190 M.E.B.
Le Chesnay Cedex Salt Lake City, Utah 84112
France kessler@cs.utah.edu
chaillou@inria.inria.fr
∂26-Oct-87 1437 @DOUGHNUT.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU suggestion for language extension
Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 26 Oct 87 14:37:12 PST
Date: Mon, 26 Oct 87 17:37 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: suggestion for language extension
To: cl@DOUGHNUT.CS.ROCHESTER.EDU
Message-ID: <871026173702.5.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: 401A CS Building, Computer Science Department, University of Rochester, Rochester NY 14627
Phone: 716-275-1118
I'd like to make a proposal, though this is not concrete enough to be handed
to the technical committee, I'm hoping it will generate some discussion.
I don't know if any of you saw my short flame in comp.lang.lisp; in summary I
am disapointed in the lack of (certain kinds of) extensibility in CL.
There is, in fact, something conceptually simple that could be added to the
spec, is upward compatible with the current language, and would make me sleep
a lot easier (though compiler writers may groan a bit):
Allow overloading of functions.
This would allow me to create my own first-class objects, since I could
overload common operators to handle (special case) the new type.
What (I think) this means to the CL implementor...
If you are a lispm manufacturer, I can imagine something like 'advise' would
pretty much do the trick, though one might like to be able to (at some point
compile in the advice on a function, make the compiler know about the new type
etc. Even create a special tag for the object and patch the microcode. But
that's probably going overboard (though it is something a lispm may be able to
do a lot easier than a SUN). For most, a function similar to the lispm advise
would be needed, since one may want to overload potentally any function.
Again, there would be no particular requirement for *efficiency*, though it
would be nice, of course, the idea would be to allow the user to create a
first-class object, be it a lazy-stream, a continuation, or whatever.
Thanks for listening,
Brad Miller
------
miller@cs.rochester.edu {...allegra!rochester!miller}
Brad Miller
University of Rochester Computer Science Department
∂26-Oct-87 1535 @DOUGHNUT.CS.ROCHESTER.EDU,@THINK.COM:barmar@Think.COM suggestion for language extension
Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 26 Oct 87 15:34:51 PST
Received: from Think.COM (THINK.COM) by DOUGHNUT.CS.ROCHESTER.EDU via INTERNET with SMTP id 8511; 26 Oct 87 18:35:09 EST
Return-Path: <barmar@Think.COM>
Received: from occam by Think.COM via CHAOS; Mon, 26 Oct 87 18:34:22 EST
Date: Mon, 26 Oct 87 18:34 EST
From: Barry Margolin <barmar@Think.COM>
Subject: suggestion for language extension
To: miller@cs.rochester.edu
Cc: cl@doughnut.cs.rochester.edu
In-Reply-To: <871026173702.5.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Message-Id: <871026183445.4.BARMAR@OCCAM.THINK.COM>
Date: Mon, 26 Oct 87 17:37 EST
From: Brad Miller <miller@acorn.cs.rochester.edu>
There is, in fact, something conceptually simple that could be added to the
spec, is upward compatible with the current language, and would make me sleep
a lot easier (though compiler writers may groan a bit):
Allow overloading of functions.
This would allow me to create my own first-class objects, since I could
overload common operators to handle (special case) the new type.
What do you mean by this? Do you mean overloading in the Ada sense,
where you specify the data types of the arguments that cause a
particular implementation of the function to be invoked? I believe CLOS
will allow this, although there will probably be some restrictions on
the built-in functions that may be converted to generic functions (my
feeling is that only functions proclaimed INLINE should be restricted).
You mentioned that overloading could be implemented using an ADVISE
feature. A simple-minded ADVISE can be implemented using existing CL
facilities, so there is no real need for extending the language:
(defmacro advise (function &body body)
(let ((new-fun (gensym)))
`(progn (setf (symbol-function ',new-fun)
(symbol-function ',function))
(defun ,function (&rest arglist)
(flet ((do-it ()
(apply ',new-fun arglist)))
.,body)))))
This defines something like the lispm :AROUND advice, except that
(do-it) is used in place of :do-it. It also doesn't support unadvise,
named advice, etc., but those merely require maintaining a database. It
also doesn't support the lispm feature that an advised function can be
redefined without affecting the advice, which requires hooks in the
implementation; however, I don't think it is necessary for the
overloading feature that Brad wants.
Another question: what particular problem does overloading solve for
you? If you want a function that is like READ-CHAR except that it does
something different when the stream argument is one of your structures,
you can do:
(defun my-read-char (stream)
(if (my-struct-p stream)
(read-char-from-my-struct stream)
(read-char stream)))
and call my-read-char in place of read-char in your program. If your
intent was to pass a my-struct to some other CL input function, such as
READ or READ-LINE, advising read-char wouldn't necessarily help (CL
gives no guarantee that READ, READ-LINE, etc. call READ-CHAR internally,
although particular CL implementations may do so).
barmar
∂26-Oct-87 2150 COMMON-LISP-mailer extending DEFSTRUCT
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 26 Oct 87 21:49:55 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 282589; Mon 26-Oct-87 23:37:47 EST
Date: Mon, 26 Oct 87 23:37 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: extending DEFSTRUCT
To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>
cc: Rick.Busdiecker@cs.cmu.edu, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <871026122502.1.DFM@WHITBY.Palladian.COM>
Message-ID: <19871027043741.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Mon, 26 Oct 87 12:25 EST
From: Don Morrison <dfm@JASPER.Palladian.COM>
If you do, you probably should make it #<name-of-structure-type NNN>
where NNN is an integer (decimal?) such that two eq structures always
have the same number, and two not eq structures don't. I believe this
corresponds pretty closely to current practice for those implementations
that do support such a beast. The major difference, I believe, is that
often NNN is currently an address that can change over time; it would
probably be cleaner for eq structures to always print the same, no
matter how manner GCs have intervened. Since the hash or whatever it is
you'd stick there would only need to be computed if you're printing the
thing, I suspect it wouldn't add any serious overhead to structures
that's not already there to support eq hash tables.
Wait a minute, EQ hash tables can't work that way; they have to work
on bignums and rationals and conses and other things that don't have
any private slot to store the hash in. And yes, adding overhead to
structures to support this would indeed be prohibitively expensive.
On the other hand, if you don't mind having things you print never
go away in the GC, you could use EQ hash tables to implement this,
and only incur a cost for structures you actually print. But not
having structures GC is a serious flaw, too.
I don't see that we could reasonably impose this on implementations.
Also, the octal address is often useful. I use it all the time
when I'm debugging the mouse input code so that I can't just point
at structures with the mouse. We used to use it a lot more, and
(sys:%find-structure-header #o234725) is sort of an idiom around
here amongst the hackers of the lower levels. (It returns the
object; it means essentially "object at address", and figures out
the type codes).
∂26-Oct-87 2206 Common-Lisp-mailer Re: suggestion for language extension
Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 26 Oct 87 22:06:14 PST
Date: Tue, 27 Oct 87 01:05 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Re: suggestion for language extension
To: Barry Margolin <barmar@Think.COM>
cc: cl@DOUGHNUT.CS.ROCHESTER.EDU
In-Reply-To: <871026183445.4.BARMAR@OCCAM.THINK.COM>
Message-ID: <871027010550.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Default-Character-Style: (:FIX :CONDENSED :NORMAL)
Fonts: CPTFONTC
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: 401A CS Building, Computer Science Department, University of Rochester, Rochester NY 14627
Phone: 716-275-1118
Date: Mon, 26 Oct 87 18:34 EST
From: Barry Margolin <barmar@Think.COM>
Date: Mon, 26 Oct 87 17:37 EST
From: Brad Miller <miller@acorn.cs.rochester.edu>
There is, in fact, something conceptually simple that could be added to the
spec, is upward compatible with the current language, and would make me sleep
a lot easier (though compiler writers may groan a bit):
Allow overloading of functions.
This would allow me to create my own first-class objects, since I could
overload common operators to handle (special case) the new type.
What do you mean by this? Do you mean overloading in the Ada sense,
where you specify the data types of the arguments that cause a
particular implementation of the function to be invoked?
Yes. Like Ada, the information would be static, unlike Ada, result type
wouldn't (necessarily) need to be taken into account. <doing such would
certainly complicate things, but perhaps be in the lisp philosophy of
run-time coercion of objects when needed.>
I believe CLOS
will allow this, although there will probably be some restrictions on
the built-in functions that may be converted to generic functions (my
feeling is that only functions proclaimed INLINE should be restricted).
I don't think this would be general enough, see following...
You mentioned that overloading could be implemented using an ADVISE
feature. A simple-minded ADVISE can be implemented using existing CL
facilities, so there is no real need for extending the language:
This (a macro) does not alter the run-time semantics of already compiled
programs, which would be necessary...
...
redefined without affecting the advice, which requires hooks in the
implementation; however, I don't think it is necessary for the
overloading feature that Brad wants.
Then again...
Another question: what particular problem does overloading solve for
you?
What I would *like* to do...
Take the example of creating something that is a (possibly infinite) list,
but lazy-eval'd. So you want to overload all the existing CL functions that
can possibly accept lists, and make them accept lazy-lists as well. Some of
them (e.g. reverse) might return an error when you pass them a lazy-list,
but most (e.g. cdr) may run the function associated with the lazy-list to
generate the next item. Once the lazy-list abstraction/type has been
defined, there should be no particular reason existing programs should not
be able to accept/deal with them, so long as the underlying functions have
been taught how to handle them. You have, with this mechanism, *extended the
language* to include the new first class object of lazy-stream, which is
considerably different than defining lazy-cons, lazy-car, .... and having
your program call these functions itself. To the programmer, the extension
is transparent. cons, car, cdr, etc. work on all objects of type list
independent of their lazyness.
The main intent (for me particularly) is to get scheme-style streams up, but
I figured other people might want to create first class objects too...
The other thing I *really* would like is scheme-style continuations, but I
suspect this sort of thing would be politically non-feasible at this point.
Overloading helps, in that I can make continuations first class objects, but
getting to just what a continuation is would still be hard since you need to
snapshot the stack... This sort of thing may be better addressed as
something CL would provide explicitly; I can't think of general underlying
mechanisms that solve continuations that would also be useful to make
generally available because of their utility in extending the language.
(without consing up infinite hair in terms of concrete language semantics).
Thanks for your interest!
Brad Miller
------
miller@cs.rochester.edu {...allegra!rochester!miller}
Brad Miller
University of Rochester Computer Science Department
∂27-Oct-87 0933 Common-Lisp-mailer re: defstruct extensions
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 09:33:07 PST
Posted-Date: Tue, 27 Oct 87 09:33:23 PST
Message-Id: <8710271733.AA15979@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA15979; Tue, 27 Oct 87 09:33:43 PST
To: COMMON-LISP@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: re: defstruct extensions
Cc: goldman@vaxa.isi.edu
Date: Tue, 27 Oct 87 09:33:23 PST
Sender: goldman@vaxa.isi.edu
The recently discussed extensions to DEFSTRUCT are reasonable and
needed improvements. But I dissent from the proposal(s) for controlling
printing, which seem like they require the use of a sledgehammer to
crack an egg -- i.e., rebinding a special variable with dynamic effect
on printing of ALL structure instances (or even all instances of a
given class), including those embedded withing fields of other
instances, when what is wanted, if Corkill's example is
representative, is a finer control over a particular instance of printing.
In fact, it looks like what is wanted here is the CALL-NEXT-METHOD
ability of CLOS. Think of PRINT-STRUCTURE as a generic operation,
with a method defined for STRUCTURE (which prints #<...>). Providing
a print-function in a defstruct can then be viewed as a syntactic device
for defining a PRINT-STRUCTURE method for that specialization of STRUCTURE.
If there is sufficient need to resolve this problem prior to any
integration of CLOS and structures, I would favor a solution that at
least "feels" like this -- e.g., a special form (DEFAULT-PRINT-STRUCTURE)
(no arguments) that could ONLY appear lexically within a structure's
print function
(defstruct
(employee
(:print-function
(lambda (employee stream print-depth)
(declare (ignore print-depth))
(cond ((and (not *print-pretty*) *print-escape*)
(DEFAULT-PRINT-STRUCTURE))
;; Pretty printing requested
(t (format stream
"{Employee: ~A}"
(employee-name employee)))))))
...)
Alternatively, and less desirable in my mind, a function
(WRITE-STRUCTURE-DEFAULT structure-instance)
could be provided to ask for an arbitrary instance to be printed with
the default structure printer.
Neil
∂27-Oct-87 0944 Common-Lisp-mailer Re: suggestion for language extension
Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 27 Oct 87 09:44:16 PST
Received: from Think.COM (THINK.COM) by DOUGHNUT.CS.ROCHESTER.EDU via INTERNET with SMTP id 8517; 27 Oct 87 12:44:34 EST
Return-Path: <barmar@Think.COM>
Received: from occam by Think.COM via CHAOS; Tue, 27 Oct 87 12:43:43 EST
Date: Tue, 27 Oct 87 12:43 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: suggestion for language extension
To: miller@cs.rochester.edu
Cc: cl@doughnut.cs.rochester.edu
In-Reply-To: <871027010550.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Message-Id: <871027124353.3.BARMAR@OCCAM.THINK.COM>
Date: Tue, 27 Oct 87 01:05 EST
From: Brad Miller <miller@acorn.cs.rochester.edu>
Date: Mon, 26 Oct 87 18:34 EST
From: Barry Margolin <barmar@Think.COM>
I believe CLOS
will allow this, although there will probably be some restrictions on
the built-in functions that may be converted to generic functions (my
feeling is that only functions proclaimed INLINE should be restricted).
I don't think this would be general enough, see following...
It seems completely general to me. Anything that isn't open-coded could
be turned into a generic function that dispatches on the data types of
its arguments. What more do you need?
You mentioned that overloading could be implemented using an ADVISE
feature. A simple-minded ADVISE can be implemented using existing CL
facilities, so there is no real need for extending the language:
This (a macro) does not alter the run-time semantics of already compiled
programs, which would be necessary...
Why doesn't it? It redefines the function you want to overload. Unless
the function you are overloading was originally a macro or open-coded
function, future calls will go to the new definition. Before we got
into the habit of customizing the Symbolics environment using ADVISE we
used something like it all the time.
What I would *like* to do...
Take the example of creating something that is a (possibly infinite) list,
but lazy-eval'd. So you want to overload all the existing CL functions that
can possibly accept lists,
That's a LOT of functions!
and make them accept lazy-lists as well.
... cons, car, cdr, etc. work on all objects of type list
independent of their lazyness.
Except that most of the functions already in the environment had CAR and
CDR compiled inline, so they won't pick up the overloaded definition.
The main intent (for me particularly) is to get scheme-style streams up, but
I figured other people might want to create first class objects too...
Scheme-style streams don't require overloading. In Scheme you use
different functions (HEAD, TAIL) to get the items of a stream from the
ones used to get items in a list (CAR, CDR). Scheme doesn't have any
special overloading support, either.
The other thing I *really* would like is scheme-style continuations, but I
suspect this sort of thing would be politically non-feasible at this point.
Overloading helps, in that I can make continuations first class objects, but
getting to just what a continuation is would still be hard since you need to
snapshot the stack...
CL already knows how to snapshot the stack, to make lexical closures.
The problem is that there are some arbitrary limitations on what a
closure can do.
This sort of thing may be better addressed as
something CL would provide explicitly; I can't think of general underlying
mechanisms that solve continuations that would also be useful to make
generally available because of their utility in extending the language.
(without consing up infinite hair in terms of concrete language semantics).
All that needs to be done to CL to make continuations as useful as they
are in Scheme is to change the extent of CATCH tags, BLOCK names, and
TAGBODY labels from dynamic to indefinite. Unfortunately, this would be
a significant change to the language, and I'm not sure that its impact
on existing implementations would be worth the gain. But if those
restrictions were lifted, the following definition of CALL/CC would
suffice:
(defmacro call/cc (function &rest args &aux (block-name (gensym)))
`(block ,block-name
(funcall ,function
#'(lambda (&rest results)
(return-from ,block-name (values-list results)))
.,args)))
I'm not a Scheme programmer, and I don't know what the value of being
able to transfer into a function that already returned is. One thing I
believe CALL/CC is used for is coroutines, and the above CL
implementation will support that; however, without tail-recursion
optimization you will get pretty deep pretty quickly.
barmar
∂27-Oct-87 1212 Common-Lisp-mailer Re: macrolet/flet/labels
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Oct 87 12:11:53 PST
Received: from Salvador.ms by ArpaGateway.ms ; 27 OCT 87 11:57:07 PST
Date: 27 Oct 87 11:18 PDT
From: masinter.pa@Xerox.COM
Subject: Re: macrolet/flet/labels
In-reply-to: pyrnj!pyramid!bein%RUTGERS:EDU:Xerox's message of 24 Oct 87
21:09
To: pyrnj!pyramid!bein@RUTGERS.EDU
cc: common-lisp@sail.stanford.edu
Message-ID: <871027-115707-1048@Xerox>
Until the issue has been resolved, it seems like a good idea to avoid
shadowing ANY function or macro in CLtL with MACROLET/FLET/LABELS, but
especially special forms.
For example, suppose that you had
(flet ((cons (x y) (cons y x)))
(unwind-protect (my-call) (my-cleanup)))
In some systems, unwind-protect might be implemented as a macro which
expands into something that invokes CONS.
The primary problem is the possibility of references to Common Lisp
functions and special forms within macros invoked within the scope of
the FLET, LABELS or MACROLET. Until there is a macro expansion mechanism
universally adopted which protects macro references from unexpected
local rebindings, you're best off avoiding the whole problem by not
shadowing functions whose references you have no control over.
∂27-Oct-87 1744 Common-Lisp-mailer integer-decode-float usage question
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 17:43:53 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA17563; Tue, 27 Oct 87 18:44:06 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA11261; Tue, 27 Oct 87 18:44:02 MST
Date: Tue, 27 Oct 87 18:44:02 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710280144.AA11261@orion.utah.edu>
Subject: integer-decode-float usage question
To: common-lisp@sail.stanford.edu
Perhaps I'm just being exceptionally dense today, but I'm having a hard
time figuring out how to convert floating point numbers on one machine
into a representation used by another machine (namely, the Motorola FFP
format). I assume that this was the reason why the function
INTEGER-DECODE-FLOAT was provided, but darned if I know how to interpret
the numbers I'm getting back from it -- the exponent of 1.0 is -23?!?
Or is that a bug in the implementation (VaxLisp)? Can anyone shed some
light on the topic?
-Sandra
-------
∂27-Oct-87 1816 Common-Lisp-mailer integer-decode-float usage question
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Oct 87 18:11:52 PST
Return-Path: <mincy@Think.COM>
Received: from zeno by Think.COM via CHAOS; Tue, 27 Oct 87 21:11:50 EST
Date: Tue, 27 Oct 87 21:14 EST
From: Jeff Mincy <mincy@Think.COM>
Subject: integer-decode-float usage question
To: sandra%orion@cs.utah.edu, common-lisp@sail.stanford.edu
In-Reply-To: <8710280144.AA11261@orion.utah.edu>
Message-Id: <871027211454.3.MINCY@ZENO.THINK.COM>
Date: Tue, 27 Oct 87 18:44:02 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Perhaps I'm just being exceptionally dense today, but I'm having a hard
time figuring out how to convert floating point numbers on one machine
into a representation used by another machine (namely, the Motorola FFP
format). I assume that this was the reason why the function
INTEGER-DECODE-FLOAT was provided, but darned if I know how to interpret
the numbers I'm getting back from it -- the exponent of 1.0 is -23?!?
Or is that a bug in the implementation (VaxLisp)? Can anyone shed some
light on the topic?
-Sandra
Having -23 as an exponent makes perfect sense if the first value that
integer-decode-float returns is (expt 2 23) or 8388608, and the
float-radix is 2. You have to look at both values together for the
exponent to make sense. To get the 1.0 back from the
integer-decode-float values do (scale-float (float 8388608) -23).
Which is (expt 2 (+ 23 -23)) or 1.
-jeff
∂27-Oct-87 2107 Common-Lisp-mailer Re: integer-decode-float usage question
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 87 21:07:20 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA22203; Tue, 27 Oct 87 22:07:27 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA11702; Tue, 27 Oct 87 22:07:23 MST
Date: Tue, 27 Oct 87 22:07:23 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710280507.AA11702@orion.utah.edu>
Subject: Re: integer-decode-float usage question
To: Jeff Mincy <mincy@think.com>
Cc: sandra%orion@cs.utah.edu, common-lisp@sail.stanford.edu
In-Reply-To: Jeff Mincy <mincy@Think.COM>, Tue, 27 Oct 87 21:14 EST
I guess the real problem I'm having is one of terminology: the "exponent"
returned by INTEGER-DECODE-FLOAT doesn't have the usual interpretation
as the power of 2 (or whatever the float radix is) that you multiply
the fractional part of the number by.
This is at least the third time I've had to do a conversion between one
floating point format and another. I've found myself wishing that, as
long as CL provides portable primitives for inquiring about the floating
point representations native to a particular implementation, it would
also provide a function like INTEGER-DECODE-FLOAT that lets you ask for
the same kinds of numbers but for some other float radix and precision.
Or at least some more specific documentation on how users can do this
themselves, given the existing primitives.
-Sandra
-------
∂28-Oct-87 0215 Common-Lisp-mailer re: defstruct extensions
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 28 Oct 87 02:15:17 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 283329; Wed 28-Oct-87 05:16:18 EST
Date: Wed, 28 Oct 87 05:16 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: re: defstruct extensions
To: goldman@vaxa.isi.edu
cc: COMMON-LISP@sail.stanford.edu
In-Reply-To: <8710271733.AA15979@vaxa.isi.edu>
Message-ID: <19871028101610.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Tue, 27 Oct 87 09:33:23 PST
From: goldman@vaxa.isi.edu
The recently discussed extensions to DEFSTRUCT are reasonable and
needed improvements. But I dissent from the proposal(s) for controlling
printing, which seem like they require the use of a sledgehammer to
crack an egg -- i.e., rebinding a special variable with dynamic effect
on printing of ALL structure instances (or even all instances of a
given class), including those embedded withing fields of other
instances, when what is wanted, if Corkill's example is
representative, is a finer control over a particular instance of printing.
[I can't parse this last over-long sentence.]
The default structure printing is no egg. It is a large boulder
that someone dropped on us. The right technology to deal with
it is not a sledgehammer, but dynamite. The one and only thing
I want to have to do with the default structure printer is to
*MAKE* *IT* *GO* *AWAY*!
The one exception to this is if I indicate that I am doing output
that is to be read by a program. The default structure printer
is something only a program could love.
The issue of how structures print is closely related to the
issue of separating the use of printer control variables for
controlling program communication from the use of printer
control variables as user-interface parameters.
In this vein, I have another proposal to make:
*PRINT-STRUCTURE-CONTENTS*
:FORCE-READABLE == force the now "standard" syntax.
T == use the now "standard" syntax unless a printer is
defined.
NIL (the recommended default at top level) = use the
#<...> syntax unless a printer is defined.
[Feel free to add finer-grain control if desired, but this
is definitely the level I would want to control this at.]
PRINTING-RANDOM-OBJECT ((object stream &key (typep t) (unique-id t))
&body body)
Used in print functions, this takes care of printing the standard
part of non-readable objects. If *PRINT-FOR-READ* is T (see below),
it signals an error. The body is responsible for printing all
of the stuff in the middle, to identify the particular structure.
:TYPEP NIL suppresses the type name at the start (leaving that
responsibility to the body), and :UNIQUE-ID NIL suppresses the
number at the end.
*PRINT-ESCAPE*
NIL == use the printer control variables.
T == use the printer control variables.
:FOR-READ = signal an error if PRINTING-RANDOM-OBJECT is called.
:FOR-READ-FORCE = skip print functions, and signal an error if
PRINTING-RANDOM-OBJECT is called (say, by the system-supplied
printer for a compiled function).
WITH-IO-ENVIRONMENT ((&Rest IO-keywords &KEY &ALLOW-OTHER-KEYS)
&Body body)
Set up the IO parameters to allow programs to communicate.
Binds all IO parameters (including any defined by local
extensions to CL) to produce the standard results. (*PRINT-ESCAPE*
is bound to :FOR-READ, *PRINT-STRUCTURE-CONTENTS* is bound to
T).
Any IO-keywords supplied override the standard values. For example,
an application may which to say:
(WITH-IO-ENVIRONMENT (:PACKAGE "MY-DATABASE" :BASE 8.)
(PRINT DATABASE STREAM))
[Actually, I really think that printer control should be on a per-stream
basis, and the printer control variables should just serve as defaults
when creating a stream. But I don't see how to change that at this late
date.]
DEFAULT-PRINT-STRUCTURE (object stream print-depth)
Print a structure in the now-standard manner.
To take your example and recast it slightly:
(defstruct
(employee
(:print-function
(lambda (employee stream print-depth)
;; This print function won't be called if *PRINT-ESCAPE*
;; is :FOR-READ-FORCE.
(case *print-escape*
(:for-read
(default-print-structure employee stream print-depth))
(otherwise
(format stream "{Employee: ~A}"
(employee-name employee))))))))
(One flaw in your example was that *PRINT-PRETTY* is only supposed
to control simple changes like whitespace and 'FOO vs (QUOTE FOO).)
Implementations would be allowed to default the printer flags
with somewhat more latitude than they are now. For example:
*print-case*, *print-level*, *print-length*, *print-array*,
*print-structure-contents*.
In addition, an implementation may provide other flags, such
as *PRINT-ARRAY-LENGTH*, (a maximum size to print using the
readable syntax for arrays), and these must be bound by
WITH-IO-ENVIRONMENT to values to producing the standard syntax.
Any program writing data for use by other programs which does
not use WITH-IO-ENVIRONMENT is in error. (Currently, any program
which doesn't simulate WITH-IO-ENVIRONMENT by hand, is going to
break whenever any user sets any control variables for whatever
reason.
∂28-Oct-87 0915 Common-Lisp-mailer Re: integer-decode-float usage question
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Oct 87 09:14:49 PST
Return-Path: <barmar@Think.COM>
Received: from occam by Think.COM via CHAOS; Wed, 28 Oct 87 12:14:47 EST
Date: Wed, 28 Oct 87 12:15 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: integer-decode-float usage question
To: Sandra J Loosemore <sandra%orion@cs.utah.edu>
Cc: Jeff Mincy <mincy@Think.COM>, common-lisp@sail.stanford.edu
In-Reply-To: <8710280507.AA11702@orion.utah.edu>
Message-Id: <871028121504.5.BARMAR@OCCAM.THINK.COM>
Date: Tue, 27 Oct 87 22:07:23 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
I guess the real problem I'm having is one of terminology: the "exponent"
returned by INTEGER-DECODE-FLOAT doesn't have the usual interpretation
as the power of 2 (or whatever the float radix is) that you multiply
the fractional part of the number by.
(integer-decode-float 1.0) => 8388608, -23, 1
(float-radix 1.0) => 2
(expt 2 -23) => 1/8388608
(* 8388608 1/8388608) => 1
So, what's your complaint? 1.0 = 8388608*2↑(-23)
If you want the fraction to be as small as possible, you can write a
function that repeatedly shifts it until the least-significant bit is 1,
incrementing the exponent as it goes. In this case you'll end up with
1, 0, 1.
This is at least the third time I've had to do a conversion between one
floating point format and another. I've found myself wishing that, as
long as CL provides portable primitives for inquiring about the floating
point representations native to a particular implementation, it would
also provide a function like INTEGER-DECODE-FLOAT that lets you ask for
the same kinds of numbers but for some other float radix and precision.
Or at least some more specific documentation on how users can do this
themselves, given the existing primitives.
INTEGER-DECODE-FLOAT does one very simple thing: it unpacks a floating
point number. The numbers it returns are generally the exact same bit
patterns as were in the float to begin with (except for the sign).
barmar
∂28-Oct-87 1033 Common-Lisp-mailer Re: integer-decode-float usage question
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 87 10:32:57 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA14775; Wed, 28 Oct 87 11:32:27 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA13639; Wed, 28 Oct 87 11:32:19 MST
Date: Wed, 28 Oct 87 11:32:19 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710281832.AA13639@orion.utah.edu>
Subject: Re: integer-decode-float usage question
To: Barry Margolin <barmar@think.com>
Cc: Sandra J Loosemore <sandra%orion@cs.utah.edu>,
Jeff Mincy <mincy@think.com>, common-lisp@sail.stanford.edu
In-Reply-To: Barry Margolin <barmar@Think.COM>, Wed, 28 Oct 87 12:15 EST
From: Barry Margolin <barmar@Think.COM>
The numbers [INTEGER-DECODE-FLOAT] returns are generally the exact same bit
patterns as were in the float to begin with (except for the sign).
All of the float formats I've ever come across assume there is an
implied radix point in front of the fraction part, and the value of the
the exponent stored in the bit pattern assumes the fraction part is
really a fraction. If the float radix is 2, the exponent of 1.0 has a
value of 1 regardless of how many bits are used to represent the
fraction. That's the case for the native Vax representations, the
Motorola FFP representation, the double precision floats handled by the
E&S PS300 ACP (an implementation directly derived from Knuth's book),
and I believe the IEEE representations as well (if my memory serves me
correctly).
The exponent returned by INTEGER-DECODE-FLOAT, which does depend on the
number of bits in the fraction part, is almost certainly not the bit
pattern actually stored in the number. (Besides, the exponent is
often stored as an unsigned excess-N number instead of in its two's
complement form.)
The way CLtL defines the "exponent" makes some sense in its own right,
but it's a different interpretation than what I believe to be the usual
one. Again, it's the terminology that got me confused in the first place.
-Sandra
-------
∂28-Oct-87 1554 Common-Lisp-mailer Re: suggestion for language extension
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Oct 87 15:54:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 28 OCT 87 15:54:24 PST
Date: 28 Oct 87 15:54 PST
From: Masinter.pa@Xerox.COM
Subject: Re: suggestion for language extension
In-reply-to: miller%ACORN.CS.ROCHESTER:EDU:Xerox's message of 26 Oct 87
15:28
To: miller@cs.rochester.EDU
cc: common-lisp@Sail.stanford.edu
Message-ID: <871028-155424-3550@Xerox>
One of the primary design goals of CommonLoops was to allow the
extensibility you describe; this certainly has been reflected in the
Common Lisp Object System proposal.
It seemed beyond the scope of the CLOS proposal to separate out exactly
which functions were extensible and which were not; too many
implementations make assumptions about what CAR can and cannot do for it
to be part of today's standard. However, CLOS certainly gives the
appropriate terminology -- far better than ADVISE. What you want to
specify are some new methods for some of the existing generic functions.
∂05-Nov-87 0001 Common-Lisp-mailer flet/labels/macrolet
Received: from ECLA.USC.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 87 00:00:51 PST
Date: Thu 5 Nov 87 00:01:23-PST
From: "Kim A. Barrett" <IIM@ECLA.USC.EDU>
Subject: flet/labels/macrolet
To: common-lisp@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12348118610.33.IIM@ECLA.USC.EDU>
It is our opinion that it is reasonable for a local function/macro to be
able to shadow a special form. If such shadowing is not allowed, it's
basically just another totally arbitrary rule that the programmer has to
remember. It also makes for some extra work for program-analyzing
programs, either in the analysis of flet/labels/macrolet forms, where it
must check the names to see if they would shadow any of the standard
special-forms, or at form-processing time (where it is currently impossible
to do portably).
Note that the description of how such programs should process a form
whose car is a symbol (on page 57 of CLtL) is wrong, in that it may not
correctly handle local definitions. The key point is that such a program
is allowed to special knowledge for 'functions' other than the 24 standard
special-forms. If it does have such knowledge, it must first examine the
local environment to see if its definition is being shadowed.
Unfortunately, there is no portable way to examine the local environment.
Actually, as I'm sitting here writing this, my thoughts keep drifting
into a diatribe against the lack of portable mechanisms for dealing with
environments. If you want to write a portable code walker that accepts an
initial environment argument, either you simply can't do it if
special-forms can be shadowed, or you have to restrict your code walker to
only knowing about the standard special forms, which means it's still
impossible, if the many complaints I've heard from people trying to write
such things is any indication.
Well, if I'm going to complain about it, I suppose I should propose a
solution, so here goes ...
It seems to me that the necessary functionality for examining the
function environment is pretty easy to describe. All you really need is
something like
(defun local-function-p (symbol environment)
"This function returns T if the specified symbol names a local
function or macro in the specified environment, and Nil otherwise.
Environment should be either the environment argument passed to a
macroexpander function (obtained with the &environment
lambda-keyword), or the environment argument to applyhook/evalhook."
...)
I would expect that, for any given implementation, it is completely
trivial to write the code for local-function-p. Does anyone know of a
counter-example? With this function available, when your code walker is
processing a form which is a list whose car is a symbol, it does the
following
;; special forms can be shadowed
(if (local-function-p (car form) environment)
(multiple-value-bind (newform macrop)
(macroexpand-1 form environment)
(if macrop
<< recurse on newform >>
<< treate the form as a function call >>
))
<< do the stuff described on page 57 of CLtL >>
)
;; special forms cannot be shadowed
(cond ((member (car form) *the-infamous-24-built-in-special-forms-names*)
<< run special code >>
)
((local-function-p (car form) environment)
(multiple-value-bind (newform macrop)
(macroexpand-1 form environment)
(if macrop
<< recurse on newform >>
<< treate the form as a function call >>
)))
(t
<< do the stuff described on page 57 of CLtL >>
))
The functionality needed for augmenting environments is less obvious to
me, since I haven't studied all that many code walkers to know what their
needs are, nor all that many implementations, to know what their quirks
are, as far as manipulation of environments is concerned. I think
something like the following would be adequate for the walkers and
implementations I have seen, but feel free to blow holes in it.
(defun augment-function-environment
(function-list environment &optional macroletp)
"Return a new environment which is the same as environment except
that the functions specified in function-list are visible.
Environment should be an environment argument passed to a
macroexpander function or applyhook/evalhook. Function-list is
something suitable for the second argument to flet/labels/macrolet.
If the optional third argument is true, they are added to the
environment as local macro definitions, otherwise as local
functions."
...)
The reason for returning a new object, rather than possibly destructively
modifying it, is so that the environment can be captured at a particular
point without risking having it get modified during further processing.
The definitions are needed for macrolet so that macroexpanding within the
augmented environment will work. I don't know if anything clever needs to
be done with the definitions for local functions. If so, then rather than
having a macroletp flag this will probably need an argument which must be
(member flet labels macrolet). Again, this seems like it should be trivial
to write for a given implementation, although I feel a lot less certain
about it for augment-function-environment than I do for local-function-p.
I can't offhand think of a reasonable data structure for implementing
environments which would have problems with this, but that doesn't mean
there aren't any.
As an argument for this being sufficient, I believe that these two
functions are all that is needed to make the PCL code walker really
portable, up to non-standard special-forms in a particular implementation.
By the way, I have no strong attachment to the names specified above.
They are only intended to be suggestive.
kab
-------
∂05-Nov-87 0116 Common-Lisp-mailer flet/labels/macrolet
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Nov 87 01:16:08 PST
Return-Path: <mincy@Think.COM>
Received: from zeno by Think.COM via CHAOS; Thu, 5 Nov 87 04:15:58 EST
Date: Thu, 5 Nov 87 04:20 EST
From: Jeff Mincy <mincy@Think.COM>
Subject: flet/labels/macrolet
To: IIM@ecla.usc.edu, common-lisp@sail.stanford.edu
In-Reply-To: <12348118610.33.IIM@ECLA.USC.EDU>
Message-Id: <871105042045.8.MINCY@ZENO.THINK.COM>
Date: Thu 5 Nov 87 00:01:23-PST
From: "Kim A. Barrett" <IIM@ecla.usc.edu>
It is our opinion that it is reasonable for a local function/macro to be
able to shadow a special form. If such shadowing is not allowed, it's
basically just another totally arbitrary rule that the programmer has to
remember. It also makes for some extra work for program-analyzing
programs, either in the analysis of flet/labels/macrolet forms, where it
must check the names to see if they would shadow any of the standard
special-forms, or at form-processing time (where it is currently impossible
to do portably).
I, just to be different, do not think that it is reasonable or desirable to
hide special-forms lexically. These forms really are special, users have to understand
them separately from other things like funtion call. Making it so that
could be lexically hidden only makes special forms superficially like other forms.
You still cant funcall a special form.
It seems to me that the necessary functionality for examining the
function environment is pretty easy to describe. All you really need is
something like
(defun local-function-p (symbol environment)
"This function returns T if the specified symbol names a local
function or macro in the specified environment, and Nil otherwise.
Environment should be either the environment argument passed to a
macroexpander function (obtained with the &environment
lambda-keyword), or the environment argument to applyhook/evalhook."
...)
I have had this problem as well. One of the few places where I've *HAD* to resort
to #+symbolics ..., #+lucid ... I would suggest that it return something different
so that lexical macros can be distinguished from lexical functions.
Say return multiple values where the first value is t if is a local function or
macro and the second value of t if the symbol is lexical macro.
I would expect that, for any given implementation, it is completely
trivial to write the code for local-function-p. Does anyone know of a
counter-example? With this function available, when your code walker is
processing a form which is a list whose car is a symbol, it does the
following
The functionality needed for augmenting environments is less obvious to
me, since I haven't studied all that many code walkers to know what their
needs are, nor all that many implementations, to know what their quirks
are, as far as manipulation of environments is concerned. I think
something like the following would be adequate for the walkers and
implementations I have seen, but feel free to blow holes in it.
I am not really convinced that this is needed. But, I havent really thought about it.
kab
-jeff
∂05-Nov-87 1950 Common-Lisp-mailer flet/labels/macrolet & environments
Received: from ECLA.USC.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 87 19:49:57 PST
Date: Thu 5 Nov 87 19:49:37-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: flet/labels/macrolet & environments
To: common-lisp@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU, mincy@THINK.COM
Message-ID: <12348334919.24.IIM@ECLA.USC.EDU>
Date: Thu, 5 Nov 87 04:20 EST
From: Jeff Mincy <mincy@Think.COM>
... These forms {special-forms -- kab} really are special, users have
to understand them seperately from other things like function call. ...
You still can't funcall a special-form.
I don't think this is an adequate argument by itself. Many macros also
have peculiar syntax, which has to be learned on a case by case basis by
the user. You also can't funcall macros. But you can locally redefine
them.
There is a certain simplicity to the description of flet &etc. It says
that withing the specified scope, named functional references which match
the specified names refer to the specified definitions. If the names of
special-forms cannot be shadowed, you have to add a statement to that
effect as an additional caveat.
Note that I am NOT arguing that it is necessarily reasonable for a user
to write such code, since it may very well break things. But this is true
for any local redefinition, especially of 'standard' names, like the
built-in Common Lisp names that are in the Lisp package. I would consider
it perfectly acceptable for a compiler to issue some sort of style warning
when it encounters a local redefinition of a standard Common Lisp function,
as long as there is some way for the user to turn it off if that is REALLY
what he means to do. I understand that some compilers already do this. In
fact, I've just added this to my todo list, for the next time I start major
surgery on our compiler.
Its interesting to note that everywhere else I can find where the issue
of possibly redefining a special-form comes up, CLtL specifically says it
is an error to do so, yet is totally silent on the subject regarding local
redefinition. Not that I'm putting this forward as an argument in favor of
allowing shadowing, since it doesn't address the question of what is the
RIGHT thing to do. I was just wondering if it was an oversight, or if it
was intentional.
As a random additional piece of dirt to throw into this mess, what
happens if you have an flet &etc in which the same name appears twice? My
guess is that, with the usual left-to-right order of evaluation, combined
with the scoping rules, the most obvious answer is that the LAST of the
definitions ends up taking precedence, and the previous one(s) get ignored.
Of course, the left-to-right ordering is kind of a red herring, since the
order is left undefined, like in a LET form, where the same question
arises. Very peculiar, and probably worth a compiler warning.
... I would suggest that it {local-function-p -- kab} return a second
value of t if the symbol is a lexical macro.
I had thought about this, and in an earlier version actually had it in,
but decided it probably isn't necessary. In the places I've seen where
this function would get used, the second value would probably only be
useful as an efficiency hack, allowing you to avoid superflously calling
macroexpand on a form that references a local function, rather than a
macro. Not being one to sneer at efficiency issues, I think I've changed
my mind again, and agree with your suggestion.
I am not really convinced that this {augment-function-environment --
kab} is needed. ...
You need something like augment-function-environment so that your code
walker can process an flet/labels/macrolet form and update the environment
you are passing around in a way that keeps it compatable with the Common
Lisp implementation's representation of environments, so that you can pass
the updated environment to macroexpand. Look at the PCL code walker for an
example of the horrible kludges people are forced to try in order to write
something that is at least semi-portable.
kab
-------
∂08-Nov-87 1426 Common-Lisp-mailer equality of structures, or *default-structure-type*
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Nov 87 14:26:38 PST
Date: Sun, 8 Nov 87 14:26:27 PST
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.STANFORD.EDU>
Subject: equality of structures, or *default-structure-type*
To: common-lisp@SAIL.STANFORD.EDU
Organization: Knowledge Systems Laboratory, CSD, Stanford University
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12349062523.26.OKUNO@SUMEX-AIM.STANFORD.EDU>
If the :type option is not specified in defstruct, the structure is
represented in an implementation-dependent manner (CLtL p.314).
However, this implementation-dependentness introduces the ambiguity of
equality of structures. Suppose that one implementation uses an array
for the default representation of a structure, while the other
implementation uses a list for it (of course, it's a silly
implementation). The equality of structures may differ on these two
implementations, since equality of array is checked by the 'eq'ness
and that of list is checked by the equality of corresponding elements
(CLtL p.80). For example,
(defstruct foo a b c)
default :type = :array
(equal (make-foo) (make-foo)) ===> nil
default :type = :list
(equal (make-foo) (make-foo)) ===> t
This observation proves that we need introduce a new global variable,
say *default-structure-type*, in order to raise the portability of
COMMON Lisp programs.
Since I cannot find any messages on this matter in the archived
files at sumex, I post this message.
- Gitchang -
-------
∂08-Nov-87 1616 Common-Lisp-mailer equality of structures, or *default-structure-type*
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Nov 87 16:16:08 PST
Received: by labrea.stanford.edu; Sun, 8 Nov 87 16:14:28 PST
Received: from bhopal.lucid.com by edsel id AA16787g; Sun, 8 Nov 87 16:08:10 PST
Received: by bhopal id AA13142g; Sun, 8 Nov 87 16:07:52 PST
Date: Sun, 8 Nov 87 16:07:52 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8711090007.AA13142@bhopal.lucid.com>
To: labrea!Okuno%SUMEX@labrea.stanford.edu
Cc: labrea!common-lisp%SAIL@labrea.stanford.edu
In-Reply-To: Hiroshi "Gitchang" Okuno's message of Sun, 8 Nov 87 14:26:27 PST <12349062523.26.OKUNO@SUMEX-AIM.STANFORD.EDU>
Subject: equality of structures, or *default-structure-type*
A defstruct not given the :type option is the one area where CL's defstruct
tries to go beyond the "record structure" semantics, and enter the area of
limited "object based" programming. It's somewhat ironic that only when
you don't specify :type do the elements of the defined structure become
full-fledged members of the common-lisp type system; i.e., they are
identifiably of of the defined type rather than the implementational type.
Many persons have criticized this merger of capabilities in defstruct. The
most popular direction, however, is not to "fix" the problem with non-:type
structures, but to hail the coming of the Common Lisp Object System, which
will do a much grander job of providing object-oriented capabilities. All
the interesting properties of defaultly-typed defstructs will be subsumed
by defclass. Then, the use of defstruct could be, conventionally, limited
to :type structures.
-- JonL --
∂09-Nov-87 0556 Common-Lisp-mailer RE: equality of structures, or *default-structure-type*
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 9 Nov 87 05:56:39 PST
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA16094; Mon, 9 Nov 87 05:57:27 PST
Date: Mon, 9 Nov 87 05:57:27 PST
Message-Id: <8711091357.AA16094@decwrl.dec.com>
From: nelson%tle.DEC@decwrl.dec.com (Beryl Elaine Nelson)
To: Okuno@SUMEX-AIM.STANFORD.EDU
Subject: RE: equality of structures, or *default-structure-type*
... The equality of structures may differ on these two
implementations, since equality of array is checked by the 'eq'ness
and that of list is checked by the equality of corresponding elements
(CLtL p.80).
- Gitchang -
This problem could be solved by specifying the result of using equal
with "default type" structures. Pathname equality was specified
separately; why not structures?
Beryl Nelson
∂09-Nov-87 1158 Common-Lisp-mailer equality of structures
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 11:58:28 PST
Posted-Date: Mon, 09 Nov 87 11:57:36 PST
Message-Id: <8711091958.AA14947@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA14947; Mon, 9 Nov 87 11:58:22 PST
To: COMMON-LISP@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: equality of structures
Cc: goldman@vaxa.isi.edu
Date: Mon, 09 Nov 87 11:57:36 PST
Sender: goldman@vaxa.isi.edu
From the standpoint of writing TRANSFORMATIONs on common lisp programs,
it would be preferable to have EQUAL well defined for structure
instances for which no :type (too bad that wasn't called :implementation)
is specified.
Personally, I would like the definition should be:
two instances are EQL iff they are EQ
two instances are EQUAL iff
a) they are instances of the same most specific structure type, and
b) the contents of all corresponding fields are EQUAL.
[This is like the current definition of EQUALP for un:TYPEed structures,
at least if you believe structures are objects that have components
-- see CLtL's definition of EQUALP.]
[However, I suspect that most implementors would rather have it defined
like to have these objects be EQUAL iff they are EQL, so they can
be implemented as arrays.]
This entire problem, I am sure, stems from the more fundamental "problem"
that EQUAL is defined to recur into components of lists, but NOT of arrays,
-- except for STRINGs and BIT-VECTORs -- a decision that could ONLY have its
roots in implementation considerations.
An alternative suggested by the earlier message,
a *default-structure-type* variable, implies making the definition of
EQUAL implementation specific. But I think it carried along with it an
implication that implementations are limitied to defaulting the
implementation of such structure instances
to the equivalent of what results from either :ARRAY or :LIST, and to
defaulting the implementation of ALL instances the same way.
Re: the suggestion that CLOS should subsume (by convention or otherwise)
uses of un:TYPEed defstruct types?
I presume that this takes care of the issue of EQUAL, because the CLOS
specifies the semantics of EQUAL for its class instances? (What is the
specification, by the way?) But I would be loathe to replace my un:TYPEed
defstructs with DEFCLASSes if I gave up substantial efficiency when I only
wanted the limited power provided by the "record structure" semantics.
Are there enough declarations available in CLOS so that I could get
my compiled accesses to slots of such instances down to the equivalent
of an array element reference?
Neil
∂09-Nov-87 1159 Common-Lisp-mailer equality of structures
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 11:58:55 PST
Posted-Date: Mon, 09 Nov 87 11:59:25 PST
Message-Id: <8711091959.AA14960@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA14960; Mon, 9 Nov 87 11:59:49 PST
To: COMMON-LISP@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: equality of structures
Cc: goldman@vaxa.isi.edu
Date: Mon, 09 Nov 87 11:59:25 PST
Sender: goldman@vaxa.isi.edu
From the standpoint of writing TRANSFORMATIONs on common lisp programs,
it would be preferable to have EQUAL well defined for structure
instances for which no :type (too bad that wasn't called :implementation)
is specified.
Personally, I would like the definition should be:
two instances are EQL iff they are EQ
two instances are EQUAL iff
a) they are instances of the same most specific structure type, and
b) the contents of all corresponding fields are EQUAL.
[This is like the current definition of EQUALP for un:TYPEed structures,
at least if you believe structures are objects that have components
-- see CLtL's definition of EQUALP.]
[However, I suspect that most implementors would rather have it defined
like to have these objects be EQUAL iff they are EQL, so they can
be implemented as arrays.]
This entire problem, I am sure, stems from the more fundamental "problem"
that EQUAL is defined to recur into components of lists, but NOT of arrays,
-- except for STRINGs and BIT-VECTORs -- a decision that could ONLY have its
roots in implementation considerations.
An alternative suggested by the earlier message,
a *default-structure-type* variable, implies making the definition of
EQUAL implementation specific. But I think it carried along with it an
implication that implementations are limitied to defaulting the
implementation of such structure instances
to the equivalent of what results from either :ARRAY or :LIST, and to
defaulting the implementation of ALL instances the same way.
Re: the suggestion that CLOS should subsume (by convention or otherwise)
uses of un:TYPEed defstruct types?
I presume that this takes care of the issue of EQUAL, because the CLOS
specifies the semantics of EQUAL for its class instances? (What is the
specification, by the way?) But I would be loathe to replace my un:TYPEed
defstructs with DEFCLASSes if I gave up substantial efficiency when I only
wanted the limited power provided by the "record structure" semantics.
Are there enough declarations available in CLOS so that I could get
my compiled accesses to slots of such instances down to the equivalent
of an array element reference?
Neil
∂09-Nov-87 1159 Common-Lisp-mailer equality of structures
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 11:59:43 PST
Posted-Date: Mon, 09 Nov 87 12:00:35 PST
Message-Id: <8711092000.AA14975@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA14975; Mon, 9 Nov 87 12:00:38 PST
To: COMMON-LISP@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: equality of structures
Cc: goldman@vaxa.isi.edu
Date: Mon, 09 Nov 87 12:00:35 PST
Sender: goldman@vaxa.isi.edu
From the standpoint of writing TRANSFORMATIONs on common lisp programs,
it would be preferable to have EQUAL well defined for structure
instances for which no :type (too bad that wasn't called :implementation)
is specified.
Personally, I would like the definition should be:
two instances are EQL iff they are EQ
two instances are EQUAL iff
a) they are instances of the same most specific structure type, and
b) the contents of all corresponding fields are EQUAL.
[This is like the current definition of EQUALP for un:TYPEed structures,
at least if you believe structures are objects that have components
-- see CLtL's definition of EQUALP.]
[However, I suspect that most implementors would rather have it defined
like to have these objects be EQUAL iff they are EQL, so they can
be implemented as arrays.]
This entire problem, I am sure, stems from the more fundamental "problem"
that EQUAL is defined to recur into components of lists, but NOT of arrays,
-- except for STRINGs and BIT-VECTORs -- a decision that could ONLY have its
roots in implementation considerations.
An alternative suggested by the earlier message,
a *default-structure-type* variable, implies making the definition of
EQUAL implementation specific. But I think it carried along with it an
implication that implementations are limitied to defaulting the
implementation of such structure instances
to the equivalent of what results from either :ARRAY or :LIST, and to
defaulting the implementation of ALL instances the same way.
Re: the suggestion that CLOS should subsume (by convention or otherwise)
uses of un:TYPEed defstruct types?
I presume that this takes care of the issue of EQUAL, because the CLOS
specifies the semantics of EQUAL for its class instances? (What is the
specification, by the way?) But I would be loathe to replace my un:TYPEed
defstructs with DEFCLASSes if I gave up substantial efficiency when I only
wanted the limited power provided by the "record structure" semantics.
Are there enough declarations available in CLOS so that I could get
my compiled accesses to slots of such instances down to the equivalent
of an array element reference?
Neil
∂09-Nov-87 1410 Common-Lisp-mailer equality of structures, or *default-structure-type*
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 9 Nov 87 14:09:56 PST
Return-Path: <@occam.think.com:barmar@Think.COM>
Received: from pozzo ([192.5.104.209]) by Think.COM; Mon, 9 Nov 87 11:36:06 EST
Received: from OCCAM.THINK.COM (occam.think.com.ARPA) by pozzo; Mon, 9 Nov 87 11:31:59 est
Date: Mon, 9 Nov 87 11:34 EST
From: Barry Margolin <barmar@Think.COM>
Subject: equality of structures, or *default-structure-type*
To: "Hiroshi \"Gitchang\" Okuno" <Okuno@sumex-aim.stanford.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <12349062523.26.OKUNO@SUMEX-AIM.STANFORD.EDU>
Message-Id: <871109113400.5.BARMAR@OCCAM.THINK.COM>
I believe the intent, but not the letter, of the specification was that
when you don't specify the type explicitly, an implementation-dependent
type that is distinguishable from all other types would be used. The
actual implementation may be as some other primitive type (list, array)
but the object will be marked in some way that it can be recognized as a
defstruct-created structure.
I believe that this interpretation is necessary in order to cause the
structure's print-function to be invoked. If structures weren't
distinguishable from other data types then they would print as those
data types print, rather than using the #S notation (or the
:PRINT-FUNCTION).
Therefore, the definition of EQUAL could be extended to explicitly
specify its interpretation given two structures of the same type.
barmar
∂09-Nov-87 1412 Common-Lisp-mailer Access to lexical environment?
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 9 Nov 87 14:12:06 PST
Return-Path: <@occam.think.com:barmar@Think.COM>
Received: from pozzo ([192.5.104.209]) by Think.COM; Mon, 9 Nov 87 13:16:56 EST
Received: from OCCAM.THINK.COM (occam.think.com.ARPA) by pozzo; Mon, 9 Nov 87 13:12:48 est
Date: Mon, 9 Nov 87 13:14 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Access to lexical environment?
To: futrell%corwin.ccs.northeastern.edu@relay.cs.net
Cc: slug@r20.utexas.edu, common-lisp@sail.stanford.edu,
futrelle%corwin.ccs.northeastern.edu@relay.cs.net
In-Reply-To: <8711090904.AA02522@Think.COM>
Message-Id: <871109131445.7.BARMAR@OCCAM.THINK.COM>
Date: Sun, 8 Nov 87 21:12:26 EST
From: futrell%corwin.ccs.northeastern.edu@relay.cs.net
Creating new syntax using Lisp -- access to lexical environment?
I am not sure how to properly develop simple extensions to Lisp
syntax (using CL). For example, suppose that I'd like to set up a
way to create new things that has the following (familiar) syntax:
(def-newthing fred (other-thing) ((n :initform (+ a b))
(ls :initform (rest ls1)))
...etc.)
Now a,b, and ls1 would typically be lexically scoped. Given this, how
do I define "def-newthing"? If I use defun, it will attempt to
evaluate (other-thing), and worse, ((n :initform ....)). This won't
work. If I use defmacro, when I pull out an initform to evaluate, such
as (+ a b), the defmacro won't allow me access to the lexical bindings
of a and b. eval has similar problems. I'm stuck. Any ideas? (There
might be a lisp group to send this to, but we don't subscribe --
anyway, I have confidence that I'll be enlightened on this by sluggers.)
The right place to ask questions like this is
COMMON-LISP@SAIL.STANFORD.EDU, and I've CCed my response there so that
other CLers can help out after I do.
For the most part, defining forms such as the above are expected to
appear at top-level. However, the standard doesn't actually say that
(except maybe for DEFUN, but I think there is some contention about
this).
In any case, the way to do what you want is to create a lexical closure,
by expanding into a use of the FUNCTION special form, and when you
actually go to use the initial form you must FUNCALL it rather than
EVALing it. Here's a simplified DEFSTRUCT that does this (I don't know
whether the standard Symbolics defstruct does it, and I'm not sure
whether the CL standard requires it):
(defmacro structure-defaults (symbol)
`(get ,symbol 'simple-structure-defaults))
(defmacro def-simple-struct (name &body components)
"Use as (def-simple-struct name (slot default) ...).
Defines NAME-SLOTn macro accessors. Use MAKE-SIMPLE-STRUCTURE
to create an instance."
(let ((component-names (mapcar #'car components))
(component-defaults (mapcar #'cadr components)))
`(progn
,@(loop for component in component-names
for i from 0
collect `(defmacro ,(intern (concatenate 'string (symbol-name name)
"-" (symbol-name component)))
(object)
`(aref ,object ,',i)))
(setf (structure-defaults ',name)
(list .,(loop for default in component-defaults
collect `(function
(lambda () ,default))))))))
(defun make-simple-structure (type &rest values)
(let* ((defaults (structure-defaults type))
(size (length defaults))
(struct (make-array size)))
(dotimes (i (length values)) ;fill in specified values
(setf (aref struct i) (nth i values)))
(do ((i (length values) (1+ i)))
((>= i size))
(setf (aref struct i) (funcall (nth i defaults))))
struct))
Another way to accomplish this would be for DEF-SIMPLE-STRUCT to include
in its expansion the definition of a function that makes the objects,
and to include the default forms in this expansion. This would define a
function in the appropriate lexical environment (not that it is unclear
whether DEFUN can be used in this way -- the Symbolics interpreter
queries you if you try to use DEFUN in a non-null environment). Here is
an example of the above that works this way:
(defmacro def-simple-struct (name &body components)
"Use as (def-simple-struct name (slot default) ...).
Defines NAME-SLOTn macro accessors, and make-NAME instance creator."
(let ((component-names (mapcar #'car components))
(component-defaults (mapcar #'cadr components)))
`(progn
,@(loop for component in component-names
for i from 0
collect `(defmacro ,(intern (concatenate 'string (symbol-name name)
"-" (symbol-name component)))
(object)
`(aref ,object ,',i)))
(setf (symbol-function
',(intern (concatenate 'string "MAKE-" (symbol-name name))))
#'(lambda (&key .,component-names)
(let ((struct (make-array ,(length component-names))))
,@(loop for name in component-names
for default in component-defaults
for i from 0
collect `(setf (aref struct ,i)
(or ,name ,default)))
struct))))))
Both of these mechanisms are essentially equivalent. The first version
creates one lexical closure per slot and stores a list of them in the
property list of the structure name symbol, and MAKE-SIMPLE-STRUCTURE
extracts and calls them. The second creates a single lexical closure
that contains all the default forms and stores it in the function cell
of the creation function, and normal function evaluation invokes it. If
you don't understand the macros (they were hard enough to write
correctly), run some examples through MEXP to see what they expand into.
barmar
∂09-Nov-87 1858 Common-Lisp-mailer Question regarding FORMAT with ~:↑ within ~:{
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 87 18:58:23 PST
Received: by labrea.stanford.edu; Mon, 9 Nov 87 18:57:58 PST
Received: from vesuvius.lucid.com by edsel id AA20827g; Mon, 9 Nov 87 18:52:11 PST
Received: by vesuvius id AA07681g; Mon, 9 Nov 87 18:53:10 PST
Date: Mon, 9 Nov 87 18:53:10 PST
From: R Dunbar Poor <edsel!r@labrea.stanford.edu>
Message-Id: <8711100253.AA07681@vesuvius.lucid.com>
To: labrea!common-lisp%sail.stanford.edu@labrea.stanford.edu
Subject: Question regarding FORMAT with ~:↑ within ~:{
I have a question regarding the correct behavior of FORMAT. Please
open up your CLtL books to page 406 and tell me what the following
construct should return:
(format nil "~:{~@?~:↑...~}" '(("a") ("b")))
MY CLAIM: It should return "a".
THE RATIONALE: According to the Steele's spec, the ~:↑ construct (with
the : modifier) should exit ALL iterations, therefore, FORMAT only gets
as far as printing the "a" before it quits. CLtL page 406 states that:
"If ~↑ is used within a ~:{ construct, then it merely terminates
the current iteration step (because in the standard case it tests
for remaining arguments of the current step only); the next
iteration step commences immediately. To terminate the entire
iteration process, use ~:↑."
OTHER PEOPLE CLAIM: It should return "a...b".
THE RATIONALE: Since ~:↑ is planning to exit the entire iteration it
should check whether there are more arguments to the entire iteration,
rather than checking for more arguments in the current sublist.
A SYMBOLICS 3600 CLAIMS: It should return "a...b"
THE RATIONALE: I don't know, but that's what I got when I typed the
example in.
In closing, I might even agree that "a...b" would be more useful
behavior, but it is not in keeping with a strict interpretation of
Steele's specification. I'd be interested in cogent comments and
clarifications.
- Robert Poor
Lucid, Inc
∂10-Nov-87 1112 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑ within ~:{
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Nov 87 11:12:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 NOV 87 11:12:26 PST
Date: Tue, 10 Nov 87 11:11:59 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Question regarding FORMAT with ~:↑ within ~:{
In-reply-to: <8711100253.AA07681@vesuvius.lucid.com>
To: R Dunbar Poor <edsel!r@labrea.stanford.edu>
Cc: common-lisp@sail.stanford.edu
Message-ID: <871110-111226-5309@Xerox>
I won't bother trying to quote your message here. Folks who missed it
should look in the archives.
The question is, what should this form return:
(format nil "~:{~@?~:↑...~}" '(("a") ("b")))
Rob wants it to return "a" since ~:? means to terminate all iterations
now. Other people, including the implementors of the Symbolics FORMAT
facility, believe that it should be "a...b" since it is required to
check for the presence or absence of any further arguments to the outer
iteration.
I believe that Symbolics (and the other people) are right. Consider the
following: the quoted paragraph from CLtL page 406 says this:
"If ~↑ is used within a ~:{ construct, then it merely terminates
the current iteration step (because in the standard case it tests
for remaining arguments of the current step only); the next
iteration step commences immediately. To terminate the entire
iteration process, use ~:↑."
In the first sentence, the claim is that ~↑ will unconditionally
terminate the current iteration step. But we know from context on the
page that this isn't true, that really it will terminate the step only
when no more arguments remain for that step. If we had wanted truly
unconditional termination, we should have used ~0↑. Thus, by the same
context, the claim that ~:↑ terminates the entire iteration must be
understood to mean that it does so only when there are no more arguments
for that iteration. If we had wanted the other meaning, we should have
used ~0:↑.
Thus, I think that a truly strict interpretation of CLtL implies that
the other people (and Symbolics) are right.
Pavel
∂10-Nov-87 1134 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑ within ~:{
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 10 Nov 87 11:34:03 PST
Received: by multimax.ARPA (5.51/25-eef)
id AA13651; Tue, 10 Nov 87 10:53:47 EST
Message-Id: <8711101553.AA13651@multimax.ARPA>
To: R Dunbar Poor <edsel!r@labrea.stanford.edu>
Cc: common-lisp@sail.stanford.edu
Subject: Re: Question regarding FORMAT with ~:↑ within ~:{
In-Reply-To: Your message of Mon, 09 Nov 87 18:53:10 -0800.
<8711100253.AA07681@vesuvius.lucid.com>
Date: Tue, 10 Nov 87 10:53:40 EST
From: Dan L. Pierson <pierson@multimax.arpa> <pierson>
>> I have a question regarding the correct behavior of FORMAT. Please
>> open up your CLtL books to page 406 and tell me what the following
>> construct should return:
>>
>> (format nil "~:{~@?~:↑...~}" '(("a") ("b")))
>>
Should return "a" for exactly the reason you gave. Otherwise "To
terminate the entire iteration process, use ~:↑." is meaningless.
KCL returns "a".
dan
∂10-Nov-87 1305 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 10 Nov 87 13:05:43 PST
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA19455; Tue, 10 Nov 87 13:06:36 PST
Date: Tue, 10 Nov 87 13:06:36 PST
Message-Id: <8711102106.AA19455@decwrl.dec.com>
From: robbins%expert.DEC@decwrl.dec.com
To: common-lisp@sail.stanford.edu
Subject: Re: Question regarding FORMAT with ~:↑
>> I have a question regarding the correct behavior of FORMAT. Please
>> open up your CLtL books to page 406 and tell me what the following
>> construct should return:
>>
>> (format nil "~:{~@?~:↑...~}" '(("a") ("b")))
>>
Should return "a" for exactly the reason you gave. Otherwise "To
terminate the entire iteration process, use ~:↑." is meaningless.
I agree with those who prefer "a"
By the way, VAX-Lisp returns "a"
-- Rich
∂10-Nov-87 1542 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 87 15:41:55 PST
Received: by ucbarpa.Berkeley.EDU (5.58/1.25)
id AA02907; Tue, 10 Nov 87 15:46:05 PST
Received: from akbar by franz (5.5/3.14)
id AA11686; Tue, 10 Nov 87 15:32:19 PST
Received: by akbar (5.5/3.14)
id AA28113; Tue, 10 Nov 87 15:26:55 PST
From: franz!akbar!layer@ucbarpa.Berkeley.EDU (Kevin Layer)
Return-Path: <akbar!layer>
Message-Id: <8711102326.AA28113@akbar>
To: common-lisp@sail.stanford.edu
Subject: Re: Question regarding FORMAT with ~:↑
Date: Tue, 10 Nov 87 15:26:53 PST
>> I have a question regarding the correct behavior of FORMAT. Please
>> open up your CLtL books to page 406 and tell me what the following
>> construct should return:
>>
>> (format nil "~:{~@?~:↑...~}" '(("a") ("b")))
>>
Franz's Allegro Common Lisp returns "a", which we feel is the correct
answer.
Kevin Layer
∂10-Nov-87 2152 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑ within ~:{
Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 10 Nov 87 21:52:21 PST
Date: 11 Nov 1987 00:51-EST
Sender: NGALL@G.BBN.COM
Subject: Re: Question regarding FORMAT with ~:↑ within ~:{
From: NGALL@G.BBN.COM
To: edsel!r@LABREA.STANFORD.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
Message-ID: <[G.BBN.COM]11-Nov-87 00:51:10.NGALL>
In-Reply-To: <8711100253.AA07681@vesuvius.lucid.com>
Date: Mon, 9 Nov 87 18:53:10 PST
From: R Dunbar Poor <edsel!r@labrea.stanford.edu>
...
(format nil "~:{~@?~:↑...~}" '(("a") ("b")))
MY CLAIM: It should return "a".
...
CLtL page 406 states that:
"If ~↑ is used within a ~:{ construct, then it merely terminates
the current iteration step (because in the standard case it tests
for remaining arguments of the current step only); the next
iteration step commences immediately. To terminate the entire
iteration process, use ~:↑."
Although I agree that a superficial reading of the above would lead
one to expect "a" to be returned, if one thinks about the intent of
the parenthetical
(because in the standard case it tests for remaining arguments of
the current step only)
one should agree that "a...b" will be returned. In refering to ~↑ as
the "standard case", which tests the arguments remaining in the
current argument sublist, this parenthetical implies that there is
an `other case', which tests `something else.' The only `other case'
discussed is ~:↑, which therefore must test `something else.' I claim
that the parentheical makes no sense if we interpret ~:↑ as testing
the same condition as ~↑. If they both test the same condition, why
have the parenthetical explanation?
If ~:↑ doesn't test the same condition as ~↑, then what does it test?
I claim that the only test that makes sense is for ~:↑ to test the
only thing that affects the "entire iteration process:" the number of
sublists. When there are no more sublists, "the entire iteration
process" is terminated.
Finally, It makes no sense for ~:↑ to test the number of args
remaining in the current sublist, since this can be acheived by the
following:
(format nil "~:{~@?~#[~0:↑~]...~}" '(("a") ("b")))
But it makes perfect sense for ~:↑ to test the number of arglists
remaining, SINCE THERE IS NO OTHER WAY TO TEST THIS.
Comments?
-- Nick
∂11-Nov-87 0806 Common-Lisp-mailer Re: Question regarding FORMAT with ~:↑ within ~:{
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 08:06:27 PST
Received: from RTS-12.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 11 Nov 87 11:03-EST
Message-Id: <2772633993-10450594@RTS-12>
Sender: cerys@RTS-12
Date: Wed, 11 Nov 87 11:06:33 EST
From: "Daniel L. Cerys" <Cerys@XX.LCS.MIT.EDU>
To: R Dunbar Poor <edsel!r@labrea.stanford.edu>
Cc: common-lisp@sail.stanford.edu
Subject: Re: Question regarding FORMAT with ~:↑ within ~:{
> The question is, what should this form return:
>
> (format nil "~:{~@?~:↑...~}" '(("a") ("b")))
Like the other MIT-based LISPM, the TI Explorer returns "a...b".
So far, Nick Gall seems to have the best explanation for this.
Dan
∂11-Nov-87 1117 Common-Lisp-mailer flet/labels/macrolet and environments
Received: from ECLA.USC.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 87 11:17:06 PST
Date: Wed 11 Nov 87 11:17:51-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: flet/labels/macrolet and environments
To: common-lisp@SAIL.STANFORD.EDU
cc: Mincy@THINK.COM, iim@ECLA.USC.EDU
Message-ID: <12349814619.24.IIM@ECLA.USC.EDU>
{ The mailer seems to have bounced the first time I sent this.
Apologies to anyone who receives it twice. kab }
Date: Thu, 5 Nov 87 04:20 EST
From: Jeff Mincy <mincy@Think.COM>
... These forms {special-forms -- kab} really are special, users have
to understand them seperately from other things like function call. ...
You still can't funcall a special-form.
I don't think this is an adequate argument by itself. Many macros also
have peculiar syntax, which has to be learned on a case by case basis by
the user. You also can't funcall macros. But you can locally redefine
them.
There is a certain simplicity to the description of flet &etc. It says
that within the specified scope, named functional references which match
the specified names refer to the specified definitions. If the names of
special-forms cannot be shadowed, you have to add a statement to that
effect as an additional caveat.
Note that I am NOT arguing that it is necessarily reasonable for a user
to write such code, since it may very well break things. But this is true
for any local redefinition, especially of 'standard' names, like the
built-in Common Lisp names that are in the Lisp package. I would consider
it perfectly acceptable for a compiler to issue some sort of style warning
when it encounters a local redefinition of a standard Common Lisp function,
as long as there is some way for the user to turn it off if that is REALLY
what he means to do. I understand that some compilers already do this. In
fact, I've just added this to my todo list, for the next time I start major
surgery on our compiler.
Its interesting to note that everywhere else I can find where the issue
of possibly redefining a special-form comes up, CLtL specifically says it
is an error to do so, yet is totally silent on the subject regarding local
redefinition. Not that I'm putting this forward as an argument in favor of
allowing shadowing, since it doesn't address the question of what is the
RIGHT thing to do. I was just wondering if it was an oversight, or if it
was intentional.
As a random additional piece of dirt to throw into this mess, what
happens if you have an flet &etc in which the same name appears twice? My
guess is that, with the usual left-to-right order of evaluation, combined
with the scoping rules, the most obvious answer is that the LAST of the
definitions ends up taking precedence, and the previous one(s) get ignored.
Of course, the left-to-right ordering is kind of a red herring, since the
order is left undefined, like in a LET form, where the same question
arises. Very peculiar, and probably worth a compiler warning.
... I would suggest that it {local-function-p -- kab} return a second
value of t if the symbol is a lexical macro.
I had thought about this, and in an earlier version actually had it in,
but decided it probably isn't necessary. In the places I've seen where
this function would get used, the second value would probably only be
useful as an efficiency hack, allowing you to avoid superflously calling
macroexpand on a form that references a local function, rather than a
macro. Not being one to sneer at efficiency issues, I think I've changed
my mind again, and agree with your suggestion.
I am not really convinced that this {augment-function-environment --
kab} is needed. ...
You need something like augment-function-environment so that your code
walker can process an flet/labels/macrolet form and update the environment
you are passing around in a way that keeps it compatable with the Common
Lisp implementation's representation of environments, so that you can pass
the updated environment to macroexpand. Look at the PCL code walker for an
example of the horrible kludges people are forced to try in order to write
something that is at least semi-portable.
kab
-------
∂11-Nov-87 1631 Common-Lisp-mailer Re: Local redefs of special forms
Received: from NRTC.NORTHROP.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 16:31:02 PST
Received: by nrtc.nrtc.northrop.com id aa03871; 11 Nov 87 16:31 PST
Date: Wed, 11 Nov 87 16:28:54 PST
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
To: common-lisp@sail.stanford.edu
Subject: Re: Local redefs of special forms
If you allow FLETS, et al, to shadow special forms, there is an implementation
issue with inline function expansions nee DEFSUBSTs. The compiler cannot
substitute the function body and optimize as some compilers now do. In fact
the body must be (re)expanded in the null lexical environment no matter what.
Consider the following example:
(defsubst foo (x) (car x))
(flet((car (l) (cdr l)))
(foo (car q)))
The value of the flet should be (cadr q) while if the compiler is not careful,
the result will be (cddr q) instead. Note, this issue has nothing to do with
special forms, it depends only on the interaction between an inline function,
the defsubst, and local function defs, the flet. In order to get the proper
semantics AND the optimization implied by using an inline function, a compiler
must mark expressions with their lexical environment. Perhaps the expression
(foo (cdr q)) in the above would need to look something like
(#<env 1> (foo (car q)))
(#<env 0) (foo (#<env 1> (car q)))
(#<env 0> (car (#<env1> (car q))))
and if the flet is inlined
(#<env 0> (car (cdr (#<env 1> q))))
at different times as the compiler elaborated the original. Note, the env
wrap around the variable is necesssary also: Think about the interactions
that might result (with more complex local fcn defs) if there is a special
declaration around an inline expansion
(let(...)
(declare ....)
(in-line-fcn reference ...) ...)
If the subst's body is just substituted AND it binds a declared variable, all
hell will break loose.
I don't think that you can get out of the delemma without some sort of env
wrapper. In any event, there needs to be a good set of primitives to
manage and interagate environments so that sexy system macros and substs
don't blow the bunnies. As long as they need to exist, why not standardize,
document, and distribute them?
∂11-Nov-87 1800 Common-Lisp-mailer Re: Local redefs of special forms
Received: from NRTC.NORTHROP.COM by SAIL.STANFORD.EDU with TCP; 11 Nov 87 16:31:02 PST
Received: by nrtc.nrtc.northrop.com id aa03871; 11 Nov 87 16:31 PST
Date: Wed, 11 Nov 87 16:28:54 PST
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
To: common-lisp@sail.stanford.edu
Subject: Re: Local redefs of special forms
If you allow FLETS, et al, to shadow special forms, there is an implementation
issue with inline function expansions nee DEFSUBSTs. The compiler cannot
substitute the function body and optimize as some compilers now do. In fact
the body must be (re)expanded in the null lexical environment no matter what.
Consider the following example:
(defsubst foo (x) (car x))
(flet((car (l) (cdr l)))
(foo (car q)))
The value of the flet should be (cadr q) while if the compiler is not careful,
the result will be (cddr q) instead. Note, this issue has nothing to do with
special forms, it depends only on the interaction between an inline function,
the defsubst, and local function defs, the flet. In order to get the proper
semantics AND the optimization implied by using an inline function, a compiler
must mark expressions with their lexical environment. Perhaps the expression
(foo (cdr q)) in the above would need to look something like
(#<env 1> (foo (car q)))
(#<env 0) (foo (#<env 1> (car q)))
(#<env 0> (car (#<env1> (car q))))
and if the flet is inlined
(#<env 0> (car (cdr (#<env 1> q))))
at different times as the compiler elaborated the original. Note, the env
wrap around the variable is necesssary also: Think about the interactions
that might result (with more complex local fcn defs) if there is a special
declaration around an inline expansion
(let(...)
(declare ....)
(in-line-fcn reference ...) ...)
If the subst's body is just substituted AND it binds a declared variable, all
hell will break loose.
I don't think that you can get out of the delemma without some sort of env
wrapper. In any event, there needs to be a good set of primitives to
manage and interagate environments so that sexy system macros and substs
don't blow the bunnies. As long as they need to exist, why not standardize,
document, and distribute them?
∂11-Nov-87 1912 Common-Lisp-mailer Missing and desired sequence function.
Received: from [128.81.41.234] by SAIL.STANFORD.EDU with TCP; 11 Nov 87 19:12:24 PST
Received: from SWAN.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 109603; Wed 11-Nov-87 18:03:54 EST
Date: Wed, 11 Nov 87 18:03 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Missing and desired sequence function.
To: common-lisp@sail.stanford.edu
Message-ID: <19871111230324.4.DCP@SWAN.SCRC.Symbolics.COM>
I would like a sequence function that gives me the "best" element of a
sequence. I want to give it a sequence, a predicate and (with keywords)
the bounds of the sequence and a key to extract the arguments for the
predicate. It returns the element of the sequence that is "predicate"
(e.g., less than) all the other elements. There are a couple ways to
implement this using existing functions, but it would be nice if CLtL
had this as part of the language if others find it a sibling of existing
functions.
Implementation 1: User SORT. Running time is n*log(n). Sort the list
and return the first element. Guarenteed to cons. This fails for zero
length sequences. Zero length sequences may want to be or signal an
error.
(defun best (sequence predicate &key key start end)
(elt (sort (subseq sequence start end) predicate :key key)
0))
Implementation 2: Use REDUCE. Running time is linear. Make a reduction
function which compares two elements and returns the best.
(defun best (sequence predicate &key key start end)
(reduce #'(lambda (elt1 elt2)
(if (funcall predicate
(funcall key elt1)
(funcall key elt2))
elt1
elt2))
sequence
:start start
:end end))
There are obviously some details missing in the above implementations;
they are to convey the concept. A better name might be CHOOSE.
Does this seem reasonably useful to add to the language?
∂11-Nov-87 2208 Common-Lisp-mailer Missing and desired sequence function.
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 11 Nov 87 22:08:30 PST
Received: from MANTIS.SPAR.CAS.SLB.COM (MANTIS.#Internet) by SPAR-20.SPAR.SLB.COM with TCP; Wed 11 Nov 87 22:09:53-PST
Date: Wed, 11 Nov 87 22:09 PST
From: Bob Kanefsky <Kanef@SPAR.SLB.COM>
Subject: Missing and desired sequence function.
To: common-lisp@sail.stanford.edu
In-Reply-To: <19871111230324.4.DCP@SWAN.SCRC.Symbolics.COM>
References: <870923091026.7.7THSON@MOTH.SPAR.CAS.SLB.COM>
Message-ID: <871111220942.4.KANEF@MANTIS.SPAR.CAS.SLB.COM>
I agree with you that this is a useful feature that is an obvious hole in
Common Lisp's sequence functions. As evidence that it's obviously needed, I
thought of it six weeks ago independently (or did you see my suggestion to
Symbolics Customer Reports, referenced above?).
Below is the implementation I used. It's an iterative approach using the MIT
LOOP macro, made ugly by the need to handle lists and vectors separately.
It's not as elegant as using SORT or REDUCE, but later I realized I wanted it
to return the position as well as the element; see below.
--Kanef
(defun minimize (sequence &key (key 'identity) (test '<))
;;A generalization of MIN that takes :KEY and :TEST arguments
;;as other Common-Lisp functions do.
;;Examples: (minimize '(1 2 3 4)) is the same as (min 1 2 3 4) but slower.
;; (minimize *people* :key 'height) finds the shortest person.
;; (minimize *people* :key 'age) finds the youngest person.
;; (minimize *people* :key 'age :test '>) finds the oldest person.
(declare (values element position key-value))
(macrolet ((doit (type)
;;I know the Symbolics implementations of the other sequence functions use a macro
;;for this called CLI::SEQUENCE-ITERATOR, but the callers of it are all in a restricted
;;source. This macro is the same idea.
(let ((iterator (case type
(list '(in))
(vector '(being the array-elements of)))))
`(loop with best-candidate = (elt sequence 0)
with best-offer = (funcall key best-candidate)
with best-index = 0
for index from 0
for candidate ,@iterator sequence
for offer = (funcall key candidate)
when (funcall test offer best-offer)
do (setq best-candidate candidate
best-offer offer
best-index index)
finally (return (values best-candidate best-index best-offer))))))
(etypecase sequence
(list (doit list))
(vector (doit vector)))))
As soon as I went back to writing the caller of the MINIMIZE function, I
realized that it would be convenient to have it return the index as well as
the element (ala POSITION as well as FIND).
(defun minimize (sequence &key (key 'identity) (test '<))
;;A generalization of MIN that takes :KEY and :TEST arguments
;;as other Common-Lisp functions do.
;;Examples: (minimize '(1 2 3 4)) is the same as (min 1 2 3 4) but slower.
;; (minimize *people* :key 'height) finds the shortest person.
;; (minimize *people* :key 'age) finds the youngest person.
;; (minimize *people* :key 'age :test '>) finds the oldest person.
(declare (values element position key-value))
(macrolet ((doit (type)
;;I know the Symbolics implementations of the other sequence functions use a macro
;;for this called CLI::SEQUENCE-ITERATOR, but the callers of it are all in a restricted
;;source. This macro is the same idea.
(let ((iterator (case type
(list '(in))
(vector '(being the array-elements of)))))
`(loop with best-candidate = (elt sequence 0)
with best-offer = (funcall key best-candidate)
with best-index = 0
for index from 0
for candidate ,@iterator sequence
for offer = (funcall key candidate)
when (funcall test offer best-offer)
do (setq best-candidate candidate
best-offer offer
best-index index)
finally (return (values best-candidate best-index best-offer))))))
(etypecase sequence
(list (doit list))
(vector (doit vector)))))
∂12-Nov-87 2250 Common-Lisp-mailer Missing and desired sequence function.
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 11 Nov 87 22:08:30 PST
Received: from MANTIS.SPAR.CAS.SLB.COM (MANTIS.#Internet) by SPAR-20.SPAR.SLB.COM with TCP; Wed 11 Nov 87 22:09:53-PST
Date: Wed, 11 Nov 87 22:09 PST
From: Bob Kanefsky <Kanef@SPAR.SLB.COM>
Subject: Missing and desired sequence function.
To: common-lisp@sail.stanford.edu
In-Reply-To: <19871111230324.4.DCP@SWAN.SCRC.Symbolics.COM>
References: <870923091026.7.7THSON@MOTH.SPAR.CAS.SLB.COM>
Message-ID: <871111220942.4.KANEF@MANTIS.SPAR.CAS.SLB.COM>
I agree with you that this is a useful feature that is an obvious hole in
Common Lisp's sequence functions. As evidence that it's obviously needed, I
thought of it six weeks ago independently (or did you see my suggestion to
Symbolics Customer Reports, referenced above?).
Below is the implementation I used. It's an iterative approach using the MIT
LOOP macro, made ugly by the need to handle lists and vectors separately.
It's not as elegant as using SORT or REDUCE, but later I realized I wanted it
to return the position as well as the element; see below.
--Kanef
(defun minimize (sequence &key (key 'identity) (test '<))
;;A generalization of MIN that takes :KEY and :TEST arguments
;;as other Common-Lisp functions do.
;;Examples: (minimize '(1 2 3 4)) is the same as (min 1 2 3 4) but slower.
;; (minimize *people* :key 'height) finds the shortest person.
;; (minimize *people* :key 'age) finds the youngest person.
;; (minimize *people* :key 'age :test '>) finds the oldest person.
(declare (values element position key-value))
(macrolet ((doit (type)
;;I know the Symbolics implementations of the other sequence functions use a macro
;;for this called CLI::SEQUENCE-ITERATOR, but the callers of it are all in a restricted
;;source. This macro is the same idea.
(let ((iterator (case type
(list '(in))
(vector '(being the array-elements of)))))
`(loop with best-candidate = (elt sequence 0)
with best-offer = (funcall key best-candidate)
with best-index = 0
for index from 0
for candidate ,@iterator sequence
for offer = (funcall key candidate)
when (funcall test offer best-offer)
do (setq best-candidate candidate
best-offer offer
best-index index)
finally (return (values best-candidate best-index best-offer))))))
(etypecase sequence
(list (doit list))
(vector (doit vector)))))
As soon as I went back to writing the caller of the MINIMIZE function, I
realized that it would be convenient to have it return the index as well as
the element (ala POSITION as well as FIND).
(defun minimize (sequence &key (key 'identity) (test '<))
;;A generalization of MIN that takes :KEY and :TEST arguments
;;as other Common-Lisp functions do.
;;Examples: (minimize '(1 2 3 4)) is the same as (min 1 2 3 4) but slower.
;; (minimize *people* :key 'height) finds the shortest person.
;; (minimize *people* :key 'age) finds the youngest person.
;; (minimize *people* :key 'age :test '>) finds the oldest person.
(declare (values element position key-value))
(macrolet ((doit (type)
;;I know the Symbolics implementations of the other sequence functions use a macro
;;for this called CLI::SEQUENCE-ITERATOR, but the callers of it are all in a restricted
;;source. This macro is the same idea.
(let ((iterator (case type
(list '(in))
(vector '(being the array-elements of)))))
`(loop with best-candidate = (elt sequence 0)
with best-offer = (funcall key best-candidate)
with best-index = 0
for index from 0
for candidate ,@iterator sequence
for offer = (funcall key candidate)
when (funcall test offer best-offer)
do (setq best-candidate candidate
best-offer offer
best-index index)
finally (return (values best-candidate best-index best-offer))))))
(etypecase sequence
(list (doit list))
(vector (doit vector)))))
∂12-Nov-87 2255 Common-Lisp-mailer Missing and desired sequence function.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 22:55:23 PST
Received: ID <WHOLEY@C.CS.CMU.EDU>; Thu 12 Nov 87 14:31:38-EST
Date: Thu, 12 Nov 1987 02:47 EST
Message-ID: <WHOLEY.12349951032.BABYL@C.CS.CMU.EDU>
From: Skef Wholey <Wholey@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Missing and desired sequence function.
Date: Thursday, 12 November 1987 01:09-EST
From: Bob Kanefsky <Kanef at SPAR.SLB.COM>
[...] later I realized I wanted it [the BEST function]
to return the position as well as the element; [...]
Following the lead of FIND, POSITION, and perhaps even COUNT, we could
add a few new functions: FIND-BEST, POSITION-BEST (I think BEST-POSITION
sounds nicer, though), and COUNT-BEST. This gives a picture of "BEST"
functions having a kind of orthagonalilty with the -IF and -IF-NOT forms
of these functions; indeed, the argument lists of these forms would be
identical to those of the -IF and -IF-NOT functions.
Also note that functions of this sort should take a :FROM-END keyword
(defaulting to NIL), so that one has control over which "best" item is
selected.
--Skef
∂12-Nov-87 1354 Common-Lisp-mailer Re: Local redefs of special forms
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 Nov 87 13:54:16 PST
Return-Path: <@occam.think.com:barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 12 Nov 87 13:54:29 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 12 Nov 87 13:54:24 EST
Date: Thu, 12 Nov 87 13:56 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: Local redefs of special forms
To: Jeff Barnett <jbarnett@nrtc.northrop.com>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8711120203.AA21595@Think.COM>
Message-Id: <871112135607.0.BARMAR@OCCAM.THINK.COM>
Date: Wed, 11 Nov 87 16:28:54 PST
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
If you allow FLETS, et al, to shadow special forms, there is an implementation
issue with inline function expansions nee DEFSUBSTs. The compiler cannot
substitute the function body and optimize as some compilers now do. In fact
the body must be (re)expanded in the null lexical environment no matter what.
Consider the following example:
(defsubst foo (x) (car x))
(flet((car (l) (cdr l)))
(foo (car q)))
While what you are saying is true, this particular case is not germaine
to the discussion, because CAR is not a special form, it is a function.
Also, if a compiler is going to do inline substitution, it should take
care to use the appropriate environment. I tried the above on a
Symbolics lispm and it simply decided not to do the inline substitution;
not optimal, but within the standard.
The problem you are describing DOES exist, but it is with macros. In
the case of inline functions, the compiler can simply punt using the
expansion if there is a name clash or use the global definition, but it
doesn't have the choice with macros. If you change the above example to
(defmacro foo (x)
`(car ,x))
you will encounter the problem. This problem that macros violate
lexical scoping is well-known, and there is ongoing research on how to
deal with it. A proposed solution was the subject of a presentation at
the 1986 Lisp & Functional Programming conference, with a title
something like "Hygienic Macro Expansion". There is a subcommittee of
X3J13 following the research, and if any acceptable solutions come up
I'm sure they will let us know about them.
barmar
∂12-Nov-87 2255 Common-Lisp-mailer Missing and desired sequence function.
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 11 Nov 87 22:08:30 PST
Received: from MANTIS.SPAR.CAS.SLB.COM (MANTIS.#Internet) by SPAR-20.SPAR.SLB.COM with TCP; Wed 11 Nov 87 22:09:53-PST
Date: Wed, 11 Nov 87 22:09 PST
From: Bob Kanefsky <Kanef@SPAR.SLB.COM>
Subject: Missing and desired sequence function.
To: common-lisp@sail.stanford.edu
In-Reply-To: <19871111230324.4.DCP@SWAN.SCRC.Symbolics.COM>
References: <870923091026.7.7THSON@MOTH.SPAR.CAS.SLB.COM>
Message-ID: <871111220942.4.KANEF@MANTIS.SPAR.CAS.SLB.COM>
I agree with you that this is a useful feature that is an obvious hole in
Common Lisp's sequence functions. As evidence that it's obviously needed, I
thought of it six weeks ago independently (or did you see my suggestion to
Symbolics Customer Reports, referenced above?).
Below is the implementation I used. It's an iterative approach using the MIT
LOOP macro, made ugly by the need to handle lists and vectors separately.
It's not as elegant as using SORT or REDUCE, but later I realized I wanted it
to return the position as well as the element; see below.
--Kanef
(defun minimize (sequence &key (key 'identity) (test '<))
;;A generalization of MIN that takes :KEY and :TEST arguments
;;as other Common-Lisp functions do.
;;Examples: (minimize '(1 2 3 4)) is the same as (min 1 2 3 4) but slower.
;; (minimize *people* :key 'height) finds the shortest person.
;; (minimize *people* :key 'age) finds the youngest person.
;; (minimize *people* :key 'age :test '>) finds the oldest person.
(declare (values element position key-value))
(macrolet ((doit (type)
;;I know the Symbolics implementations of the other sequence functions use a macro
;;for this called CLI::SEQUENCE-ITERATOR, but the callers of it are all in a restricted
;;source. This macro is the same idea.
(let ((iterator (case type
(list '(in))
(vector '(being the array-elements of)))))
`(loop with best-candidate = (elt sequence 0)
with best-offer = (funcall key best-candidate)
with best-index = 0
for index from 0
for candidate ,@iterator sequence
for offer = (funcall key candidate)
when (funcall test offer best-offer)
do (setq best-candidate candidate
best-offer offer
best-index index)
finally (return (values best-candidate best-index best-offer))))))
(etypecase sequence
(list (doit list))
(vector (doit vector)))))
As soon as I went back to writing the caller of the MINIMIZE function, I
realized that it would be convenient to have it return the index as well as
the element (ala POSITION as well as FIND).
(defun minimize (sequence &key (key 'identity) (test '<))
;;A generalization of MIN that takes :KEY and :TEST arguments
;;as other Common-Lisp functions do.
;;Examples: (minimize '(1 2 3 4)) is the same as (min 1 2 3 4) but slower.
;; (minimize *people* :key 'height) finds the shortest person.
;; (minimize *people* :key 'age) finds the youngest person.
;; (minimize *people* :key 'age :test '>) finds the oldest person.
(declare (values element position key-value))
(macrolet ((doit (type)
;;I know the Symbolics implementations of the other sequence functions use a macro
;;for this called CLI::SEQUENCE-ITERATOR, but the callers of it are all in a restricted
;;source. This macro is the same idea.
(let ((iterator (case type
(list '(in))
(vector '(being the array-elements of)))))
`(loop with best-candidate = (elt sequence 0)
with best-offer = (funcall key best-candidate)
with best-index = 0
for index from 0
for candidate ,@iterator sequence
for offer = (funcall key candidate)
when (funcall test offer best-offer)
do (setq best-candidate candidate
best-offer offer
best-index index)
finally (return (values best-candidate best-index best-offer))))))
(etypecase sequence
(list (doit list))
(vector (doit vector)))))
∂12-Nov-87 2309 Common-Lisp-mailer Missing and desired sequence function.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 87 22:55:23 PST
Received: ID <WHOLEY@C.CS.CMU.EDU>; Thu 12 Nov 87 14:31:38-EST
Date: Thu, 12 Nov 1987 02:47 EST
Message-ID: <WHOLEY.12349951032.BABYL@C.CS.CMU.EDU>
From: Skef Wholey <Wholey@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Missing and desired sequence function.
Date: Thursday, 12 November 1987 01:09-EST
From: Bob Kanefsky <Kanef at SPAR.SLB.COM>
[...] later I realized I wanted it [the BEST function]
to return the position as well as the element; [...]
Following the lead of FIND, POSITION, and perhaps even COUNT, we could
add a few new functions: FIND-BEST, POSITION-BEST (I think BEST-POSITION
sounds nicer, though), and COUNT-BEST. This gives a picture of "BEST"
functions having a kind of orthagonalilty with the -IF and -IF-NOT forms
of these functions; indeed, the argument lists of these forms would be
identical to those of the -IF and -IF-NOT functions.
Also note that functions of this sort should take a :FROM-END keyword
(defaulting to NIL), so that one has control over which "best" item is
selected.
--Skef
∂13-Nov-87 1122 Common-Lisp-mailer Request for adding to mailing list
Received: from GORT.CS.BUFFALO.EDU by SAIL.STANFORD.EDU with TCP; 13 Nov 87 11:22:38 PST
Received: by gort.cs.Buffalo.EDU (5.58/1.1)
id AA24330; Fri, 13 Nov 87 14:21:06 EST
Date: Fri, 13 Nov 87 14:21:06 EST
From: kumard@cs.Buffalo.EDU (Deepak Kumar)
Message-Id: <8711131921.AA24330@gort.cs.Buffalo.EDU>
To: Common-Lisp@sail.stanford.edu
Subject: Request for adding to mailing list
Please add the following address to your mailing list. It is a local
alias for Lisp wiz's. Thank you.
lispwiz@gort.cs.buffalo.edu
Deepak.
∂13-Nov-87 1559 Common-Lisp-mailer destructuring in macrolet?
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Nov 87 15:59:33 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Nov 87 18:40-EST
Received: from JASPER.Palladian.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 67786; 13 Nov 87 18:39:05-EST
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 14069; 13 Nov 87 18:32:36-EST
Date: Fri, 13 Nov 87 18:36 EST
From: Don Morrison <dfm@JASPER.Palladian.COM>
Subject: destructuring in macrolet?
To: common-lisp@sail.stanford.edu
Message-ID: <871113183615.4.DFM@WHITBY.Palladian.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>
The language on page 146 of CLtL clearly implies that macrolet does not support
defmacro-style arglist destructuring:
Defmacro, unlike any other COMMON LISP construct that has a lambda-list as
part of its syntax, provides an additional facility known as destructuring.
These seems like an oversight. Both implementations I tried (Symbolics and
Lucid, which latter is usually fairly strict about supplying only those features
that CLtL requires) do, in fact, support destructuring in macrolet. While any
implementation can clearly support destructuring within macro, it would be nice
if Common LISP required all implementations to do so, so that it can be used in
portable code. I can see no reason, aesthetic or implementational, for
prohibiting it, once you accept that macrolet's going to exist at all.
∂13-Nov-87 1640 Common-Lisp-mailer destructuring in macrolet?
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 13 Nov 87 16:40:20 PST
Return-Path: <@Think.COM:barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 13 Nov 87 19:39:39 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 13 Nov 87 19:39:34 EST
Date: Fri, 13 Nov 87 19:41 EST
From: Barry Margolin <barmar@Think.COM>
Subject: destructuring in macrolet?
To: Don Morrison <DFM%JASPER@live-oak.lcs.mit.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <871113183615.4.DFM@WHITBY.Palladian.COM>
Message-Id: <871113194113.8.BARMAR@OCCAM.THINK.COM>
Date: Fri, 13 Nov 87 18:36 EST
From: Don Morrison <dfm@jasper.palladian.com>
The language on page 146 of CLtL clearly implies that macrolet does not support
defmacro-style arglist destructuring:
Defmacro, unlike any other COMMON LISP construct that has a lambda-list as
part of its syntax, provides an additional facility known as destructuring.
According to the definition of MACROLET on page 113, it doesn't take a
lambda-list, it takes a "varlist". And at the top of page 114 it says
"MACROLET ... defines local macros, using the same format used by
DEFMACRO." I interpret that to mean that since DEFMACRO destructures,
so does MACROLET.
barmar
∂13-Nov-87 2016 Common-Lisp-mailer Re: Local redefs of special forms
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 Nov 87 20:15:56 PST
Received: from relay2.cs.net by RELAY.CS.NET id ad14665; 13 Nov 87 22:27 EST
Received: from csl.ti.com by RELAY.CS.NET id ae15242; 13 Nov 87 22:24 EST
Received: from Kelvin by tilde id AA09293; Fri, 13 Nov 87 20:24:03 CST
Message-Id: <2772843873-1355116@Kelvin>
Sender: GRAY%kelvin.csc.ti.com@RELAY.CS.NET
Date: Fri, 13 Nov 87 20:24:33 CST
From: David N Gray <Gray%dsg.csc.ti.com@RELAY.CS.NET>
To: COMMON-LISP@SAIL.STANFORD.EDU
Subject: Re: Local redefs of special forms
> From: Jeff Barnett <jbarnett@nrtc.northrop.com>
> Date: 12 Nov 87 05:21:47 GMT
>
> If you allow FLETS, et al, to shadow special forms, there is an implementation
> issue with inline function expansions nee DEFSUBSTs. The compiler cannot
> substitute the function body and optimize as some compilers now do. In fact
> the body must be (re)expanded in the null lexical environment no matter what.
> Consider the following example:
>
> (defsubst foo (x) (car x))
>
> (flet((car (l) (cdr l)))
> (foo (car q)))
>
> The value of the flet should be (cadr q) while if the compiler is not careful,
> the result will be (cddr q) instead. ...
Jeff,
But DEFSUBST is not part of Common Lisp, and I imagine that this is part
of the reason it isn't. Furthermore, DEFSUBSTs and INLINE functions are
not the same thing. Doing it the Common Lisp way:
(proclaim '(inline foo))
(defun foo (x) (car x))
the compiler is required to ensure that any inline expansion preserves
the semantics of the function call. Rather than attempting to achieve
this as a source transformation, our compiler does the expansion during
compilation, after all local function and variable names have been
replaced by pointers to the appropriate symbol table entries. Thus for
something that can be done by either a macro or inline function (a
DEFSUBST is considered to be a macro in this context), it is preferable
to use an inline function and let the compiler worry about getting the
environments right. The problem remains for things that have to be
implemented as macros because they don't follow the syntax or semantics
of a function call.
-- David Gray
∂13-Nov-87 2018 Common-Lisp-mailer destructuring in macrolet?
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 13 Nov 87 16:40:20 PST
Return-Path: <@Think.COM:barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 13 Nov 87 19:39:39 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 13 Nov 87 19:39:34 EST
Date: Fri, 13 Nov 87 19:41 EST
From: Barry Margolin <barmar@Think.COM>
Subject: destructuring in macrolet?
To: Don Morrison <DFM%JASPER@live-oak.lcs.mit.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <871113183615.4.DFM@WHITBY.Palladian.COM>
Message-Id: <871113194113.8.BARMAR@OCCAM.THINK.COM>
Date: Fri, 13 Nov 87 18:36 EST
From: Don Morrison <dfm@jasper.palladian.com>
The language on page 146 of CLtL clearly implies that macrolet does not support
defmacro-style arglist destructuring:
Defmacro, unlike any other COMMON LISP construct that has a lambda-list as
part of its syntax, provides an additional facility known as destructuring.
According to the definition of MACROLET on page 113, it doesn't take a
lambda-list, it takes a "varlist". And at the top of page 114 it says
"MACROLET ... defines local macros, using the same format used by
DEFMACRO." I interpret that to mean that since DEFMACRO destructures,
so does MACROLET.
barmar
∂13-Nov-87 2018 Common-Lisp-mailer destructuring in macrolet?
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Nov 87 15:59:33 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 13 Nov 87 18:40-EST
Received: from JASPER.Palladian.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 67786; 13 Nov 87 18:39:05-EST
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 14069; 13 Nov 87 18:32:36-EST
Date: Fri, 13 Nov 87 18:36 EST
From: Don Morrison <dfm@JASPER.Palladian.COM>
Subject: destructuring in macrolet?
To: common-lisp@sail.stanford.edu
Message-ID: <871113183615.4.DFM@WHITBY.Palladian.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>
The language on page 146 of CLtL clearly implies that macrolet does not support
defmacro-style arglist destructuring:
Defmacro, unlike any other COMMON LISP construct that has a lambda-list as
part of its syntax, provides an additional facility known as destructuring.
These seems like an oversight. Both implementations I tried (Symbolics and
Lucid, which latter is usually fairly strict about supplying only those features
that CLtL requires) do, in fact, support destructuring in macrolet. While any
implementation can clearly support destructuring within macro, it would be nice
if Common LISP required all implementations to do so, so that it can be used in
portable code. I can see no reason, aesthetic or implementational, for
prohibiting it, once you accept that macrolet's going to exist at all.
∂13-Nov-87 2303 Common-Lisp-mailer destructuring in macrolet?
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Nov 87 23:03:03 PST
Received: by labrea.stanford.edu; Fri, 13 Nov 87 23:01:21 PST
Received: from bhopal.lucid.com by edsel id AA05420g; Fri, 13 Nov 87 22:50:27 PST
Received: by bhopal id AA14252g; Fri, 13 Nov 87 22:50:26 PST
Date: Fri, 13 Nov 87 22:50:26 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8711140650.AA14252@bhopal.lucid.com>
To: labrea!DFM%Palladian.COM@labrea.stanford.edu
Cc: labrea!barmar%think.com@labrea.stanford.edu,
labrea!common-lisp%sail@labrea.stanford.edu
In-Reply-To: Don Morrison's message of Fri, 13 Nov 87 18:36 EST <871113183615.4.DFM@WHITBY.Palladian.COM>
Subject: destructuring in macrolet?
It certainly would be ill-design to have a substantially different syntax
for the lexically-local versions of definers than for the global ones.
-- JonL --
∂14-Nov-87 0139 Common-Lisp-mailer reduce should allow an accessor function to be specified
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 87 01:39:19 PST
Return-Path: <bromley@Think.COM>
Received: from pozzo by Think.COM; Sat, 14 Nov 87 04:38:39 EST
Received: by pozzo; Sat, 14 Nov 87 04:38:32 est
Date: Sat, 14 Nov 87 04:38:32 est
From: Mark Bromley <bromley@Think.COM>
Message-Id: <8711140938.AA17929@pozzo>
To: common-lisp@Think.COM
Subject: reduce should allow an accessor function to be specified
Currently, the function is directly applied to the elements of the sequence.
This limits the utility of reduce. Summing the cars of a sequence of conses is
cumbersome using reduce, and is possible only because numbers can be
distinguished from conses at run time. E.g.
(reduce #'(lambda (a b) (+ (if (consp a) (car a) a) (if (consp b) (car b) b))) sequence)
It would be much more natural to be able to use the following
(reduce #'+ sequence :key #'car).
Mark Bromley
bromley@think.com
∂14-Nov-87 0826 Common-Lisp-mailer reduce should allow an accessor function to be specified
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 87 08:26:05 PST
Return-Path: <STEVER%OZ.AI.MIT.EDU@ai.ai.mit.edu>
Received: from OZ.AI.MIT.EDU (AI.AI.MIT.EDU) by Think.COM; Sat, 14 Nov 87 11:25:23 EST
Date: Sat, 14 Nov 1987 11:26 EST
Message-Id: <STEVER.12350569792.BABYL@MIT-OZ>
From: STEVER%OZ.AI.MIT.EDU@xx.lcs.mit.edu
To: Mark Bromley <bromley@Think.COM>
Cc: common-lisp@Think.COM
Subject: reduce should allow an accessor function to be specified
In-Reply-To: Msg of 14 Nov 1987 04:38-EST from Mark Bromley <bromley at Think.COM>
Date: Saturday, 14 November 1987 04:38-EST
From: Mark Bromley <bromley at Think.COM>
[request for :KEY argument to REDUCE]
Summing the cars of a sequence of conses is cumbersome using
reduce:
(reduce #'(lambda (a b)
(+ (if (consp a) (car a) a)
(if (consp b) (car b) b))) sequence)
Could you clean this up by using:
(reduce #'(lambda (total cons) (+ total (car cons)))
sequence
:initial-value 0)
???
It's still not pretty, but it's a bit closer to 'nice'. It treats
empty sequences differently, though. My version returns 0 (the
:INITIAL-VALUE argument), while the other signals an error (the LAMBDA is
called with 0 arguments).
It would be much more natural to be able to use the following
(reduce #'+ sequence :key #'car).
I agree. :KEY is a much more elegant way to solve the problem.
-- Stephen
∂14-Nov-87 0922 Common-Lisp-mailer reduce should allow an accessor function to be specified
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 87 09:22:37 PST
Return-Path: <DCP@elephant-butte.scrc.symbolics.com>
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by Think.COM; Sat, 14 Nov 87 12:21:46 EST
Received: from SWAN.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 235305; Sat 14-Nov-87 12:21:32 EST
Date: Sat, 14 Nov 87 12:21 EST
From: David C. Plummer <DCP@quabbin.scrc.symbolics.com>
Subject: reduce should allow an accessor function to be specified
To: Mark Bromley <bromley@Think.COM>, common-lisp@Think.COM
In-Reply-To: <8711140938.AA17929@pozzo>
Message-Id: <19871114172119.6.DCP@SWAN.SCRC.Symbolics.COM>
Date: Sat, 14 Nov 87 04:38:32 est
From: Mark Bromley <bromley@Think.COM>
...
It would be much more natural to be able to use the following
(reduce #'+ sequence :key #'car).
Several people have suggested this functionality and I think most of us
think it is reasonable. Many people also believe the :KEY is not the
right keyword for extraction on the grounds that keys are for
predicates, not for operators. We even had a naming contest for the
name of extraction keyword. I don't remember if there was a clear
winner.
I really don't know what to do with this conversation. We've been over
this about 5 times now and it seems like beating a dead horse to have
another long discussion. On the other hand, we never reached
consensus/conclusion during any of those previous attempts, so this
issue will come up again and again until the functionality exists.
∂14-Nov-87 1405 Common-Lisp-mailer Re: Local redefs of special forms
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 87 14:05:23 PST
Return-Path: <@Think.COM:barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Sat, 14 Nov 87 17:04:41 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Sat, 14 Nov 87 17:04:36 EST
Date: Sat, 14 Nov 87 17:06 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: Local redefs of special forms
To: David N Gray <Gray%dsg.csc.ti.com@relay.cs.net>
Cc: COMMON-LISP@sail.stanford.edu
In-Reply-To: <2772843873-1355116@Kelvin>
Message-Id: <871114170611.4.BARMAR@OCCAM.THINK.COM>
Date: Fri, 13 Nov 87 20:24:33 CST
From: David N Gray <Gray%dsg.csc.ti.com@relay.cs.net>
Jeff,
But DEFSUBST is not part of Common Lisp, and I imagine that this is part
of the reason it isn't. Furthermore, DEFSUBSTs and INLINE functions are
not the same thing. Doing it the Common Lisp way:
(proclaim '(inline foo))
(defun foo (x) (car x))
On Symbolics Lispms, DEFSUBST is simply a macro, and
(defsubst foo (x) (car x))
expands into precisely the above PROCLAIM followed by DEFUN.
barmar
∂14-Nov-87 1417 Common-Lisp-mailer reduce should allow an accessor function to be specified
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 87 14:16:10 PST
Return-Path: <@Think.COM:barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Sat, 14 Nov 87 17:15:34 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Sat, 14 Nov 87 17:14:30 EST
Date: Sat, 14 Nov 87 17:16 EST
From: Barry Margolin <barmar@Think.COM>
Subject: reduce should allow an accessor function to be specified
To: Mark Bromley <bromley@Think.COM>
Cc: common-lisp@Think.COM
In-Reply-To: <8711140938.AA17929@pozzo>
Message-Id: <871114171605.6.BARMAR@OCCAM.THINK.COM>
Date: Sat, 14 Nov 87 04:38:32 est
From: Mark Bromley <bromley@Think.COM>
Currently, the function is directly applied to the elements of the sequence.
This limits the utility of reduce. Summing the cars of a sequence of conses is
cumbersome using reduce, and is possible only because numbers can be
distinguished from conses at run time. E.g.
(reduce #'(lambda (a b) (+ (if (consp a) (car a) a) (if (consp b) (car b) b))) sequence)
It would be much more natural to be able to use the following
(reduce #'+ sequence :key #'car).
A better interim solution, except for the fact that it conses more,
would be to use
(reduce #'+ (map 'vector #'car sequence))
This doesn't depend on distinguishing previous results from input.
barmar
∂14-Nov-87 1453 Common-Lisp-mailer questions about CLOS [original subject: equality of structures]
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Nov 87 14:52:54 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 279905; Sat 14-Nov-87 17:52:14 EST
Date: Sat, 14 Nov 87 17:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: questions about CLOS [original subject: equality of structures]
To: goldman@vaxa.isi.edu
cc: COMMON-LISP@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <8711092000.AA14975@vaxa.isi.edu>
Message-ID: <19871114225202.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 09 Nov 87 12:00:35 PST
From: goldman@vaxa.isi.edu
Re: the suggestion that CLOS should subsume (by convention or otherwise)
uses of un:TYPEed defstruct types?
I presume that this takes care of the issue of EQUAL, because the CLOS
specifies the semantics of EQUAL for its class instances? (What is the
specification, by the way?)
CLOS does not currently say anything about how the functions EQUAL, EQUALP,
and EQL behave on instances of standard classes (you can read the last four
words as equivalent to "user-defined objects"). It also doesn't say
anything about the type-specific equality functions CHAR-EQUAL,
CHAR-NOT-EQUAL, TREE-EQUAL, STRING-EQUAL, and STRING-NOT-EQUAL, nor
the 6 type-specific = and /= functions.
It would fit the structure of CLOS to say that EQUAL and EQUALP will be
expanded to generic functions whose behavior can be extended by defining
methods. I don't think we would want to allow extending EQL or the
type-specific functions, since CLOS does not claim to be so powerful as
to allow you to create new types of numbers, characters, or strings.
Extending EQ would not make any sense, of course.
I suspect the reason CLOS currently shys away from EQUAL and EQUALP is
that the equality predicates in Common Lisp are clearly not very well
chosen and beg for a lot of cleaning up based on a better theory of what
we want. To give just one example, it's peculiar that comparing arrays
element-by-element has been bundled together with ignoring alphabetic case.
It's probably better to wait for Common Lisp to get its act together
before extending CLOS into this area; clearly, equality methods can be
added later to the standard or to an individual implementation without
any incompatibilities, so there's no rush.
A possible additional reason is that CLOS does not deal terribly well
with symmetric two-argument functions such as EQUAL. It's possible to
specialize them, but you usually have to define a lot of seemingly
extraneous methods, since the generic function dispatch mechanism has
no concept of commutativity nor of type translation.
But I would be loathe to replace my un:TYPEed
defstructs with DEFCLASSes if I gave up substantial efficiency when I only
wanted the limited power provided by the "record structure" semantics.
Are there enough declarations available in CLOS so that I could get
my compiled accesses to slots of such instances down to the equivalent
of an array element reference?
As an implementation-independent language specification, CLOS does not
and cannot directly address this issue. However, it's clear what would
generally need to be declared to allow implementations to do something
like that, although you would have to look at each individual implementation
to see whether it was faster or slower than arrays with declarations;
you might even find an implementation where slot access was faster than
array access even without declarations. Basically what you need to declare
is that the class cannot be redefined or subclassed. Some members of the
CLOS subcommittee volunteered to propose declaration names and syntaxes
to allow for this type of optimization, but they haven't finished yet.
However, it is intended that most CLOS implementations either be very
efficient or have a way to make them very efficient through declarations.
∂15-Nov-87 1814 Common-Lisp-mailer destructuring in macrolet?
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 87 18:14:43 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 15 Nov 87 21:12:35-EST
Date: Sun, 15 Nov 1987 21:12 EST
Message-ID: <FAHLMAN.12350938688.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: destructuring in macrolet?
In-reply-to: Msg of 13 Nov 1987 18:36-EST from Don Morrison <dfm at JASPER.Palladian.COM>
The language on page 146 of CLtL clearly implies that macrolet does
not support defmacro-style arglist destructuring:
Defmacro, unlike any other COMMON LISP construct that has a
lambda-list as part of its syntax, provides an additional
facility known as destructuring.
Well, the definition of macrolet says that it uses the same format as
defmacro, and I read that as requiring the same handling of the arglist.
I think that the use of the phrase "any other" in the paragraph you cite
is just a bit of sloppy wording.
-- Scott
∂16-Nov-87 1852 Common-Lisp-mailer [Question regarding FORMAT with ~:↑ within ~:{]
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 87 18:52:22 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 16 Nov 87 21:51-EST
Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 68043; 16 Nov 87 21:45:06-EST
Received: from HPHCS_.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 86411; Mon 16-Nov-87 20:51:58-EST
Date: Mon, 16 Nov 1987 20:02 EST
From: ejs%acorn@oak.lcs.mit.edu
To: R Dunbar Poor <edsel!r@labrea.stanford.edu>
Subject: [Question regarding FORMAT with ~:↑ within ~:{]
cc: common-lisp@sail.stanford.edu
> Date: Mon, 9 Nov 87 18:53:10 PST
> From: R Dunbar Poor <edsel!r@labrea.stanford.edu>
> To: labrea!common-lisp%sail.stanford.edu@labrea.stanford.edu
> Subject: Question regarding FORMAT with ~:↑ within ~:{
>
> ...
>
> (format nil "~:{~@?~:↑...~}" '(("a") ("b")))
>
>
> MY CLAIM: It should return "a".
>
For what it's worth, GCLISP 3.0 returns "a" as well.
∂17-Nov-87 1609 Common-Lisp-mailer fill-pointers and adjust-array
Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 17 Nov 87 16:09:21 PST
Received: by RUTGERS.EDU (5.54/1.14) with UUCP
id AA24821; Tue, 17 Nov 87 19:12:44 EST
Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424)
id AA26981; Tue, 17 Nov 87 15:10:51 PST
Received: by pyrnova.pyramid.COM (5.51/OSx4.0b-870424)
id AA28461; Tue, 17 Nov 87 15:11:38 PST
Date: 17 Nov 1987 15:11 PST
From: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Subject: fill-pointers and adjust-array
To: common-lisp@sail.stanford.edu@RUTGERS.EDU
Message-Id: <564186732/bein@pyrnova>
Does anyone have a clear idea (page 297 CLtL) of what is supposed
to happen to the fill-pointer (this assumes the array is a vector)
when none is specified in the argument list to ADJUST-ARRAY?
I could imagine:
(1) Reset it to the new length of the array.
(2) Reset it to 0.
(3) Reset it to the minimum of the new length and the current value.
(4) Not changing it.
I am somewhat uncomfortable with it changing and would prefer
something in the spec which reads:
The :fill-pointer argument defaults to the current value of
the vector's fill-pointer. If the fill-pointer is out of bounds
after any adjustment, an error should be signaled.
With this there would be no fuzziness about the fill-pointer changing
magically and it would be well defined in the same way it is in the
other places where fill-pointers have special meaning.
Comments?
--David
p.s. Sorry if this has been answered sometime in the past.
∂17-Nov-87 1609 Common-Lisp-mailer fill-pointers and adjust-array
Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 17 Nov 87 16:09:23 PST
Received: by RUTGERS.EDU (5.54/1.14) with UUCP
id AA24830; Tue, 17 Nov 87 19:12:55 EST
Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424)
id AA27328; Tue, 17 Nov 87 15:34:47 PST
Received: by pyrnova.pyramid.COM (5.51/OSx4.0b-870424)
id AA29596; Tue, 17 Nov 87 15:35:34 PST
Date: 17 Nov 1987 15:30-PST
From: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Subject: fill-pointers and adjust-array
To: common-lisp@sail.stanford.edu@RUTGERS.EDU
Message-Id: <564190247/bein@pyrnova>
Regarding the last message, I think that ADJUST-ARRAY should have the
following semantics for its :fill-pointer argument.
(1) If :fill-pointer is NIL or not supplied, it defaults to the
current value of the vector's fill-pointer.
(2) If :fill-pointer is T, then the fill-pointer is set to the
minimum of its current value or the length of the resulting
vector.
(3) Otherwise, :fill-pointer should be a non-negative integer less than
or equal to the size of the resulting array.
In all cases, an error occurs if the final value of the fill-pointer
is out of bounds.
--David
∂17-Nov-87 2058 Common-Lisp-mailer Implementation Questions
Received: from LINDY.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Nov 87 20:58:02 PST
Received: by lindy.stanford.edu; Tue, 17 Nov 87 20:55:47 PST
Received: by Forsythe.Stanford.EDU; Tue, 17 Nov 87 20:56:34 PST
Date: Tue, 17 Nov 87 22:55 CDT
From: <LINNDR%VUENGVAX.BITNET@forsythe.stanford.edu> (David Linn)
Subject: Implementation Questions
To: common-lisp@sail.stanford.edu
X-Original-To: common-lisp@sail.stanford.edu, LINNDR
The recent discussion on CL environments sent me back to my CLtL
in hopes that I could better understand what was being discussed.
Thie review of CLtL revealed several topics that I clearly do not
understand. I apologize in advance if these have been discussed before
but I can find no clear answer in CLtL.
1) DEFUN - Is this a special form or a macro? From CLtL, p. 67:
The _defun_ special form is the usual means for defining named
functions.
The very next line declares that defun is a [Macro]. This view is
supported by the absence of defun from the list of special forms on
page 57. (BTW, the index entry for defun muddies the water by
listing page 57 (not 67) as the first entry, the entry which for
(all?) other defined words is the page of the definition.)
If defun is a macro, to what does it expand? My best guess would be
a (setf (symbol-function 'name) ...) based on the discussion of
symbol-function on page 90. My question then becomes: Into what
does the setf form expand? Is it intended that the update function
for symbol-value have an implmentation-dependent name?
The same sort of question applies to the update function for
macro-function.
2) LAMBDA-LISTS - Is the order of lambda-list keywords fixed? (p. 60)
Will the order alway be &optional/&rest/&key/&aux (meaning that
if the keyword is used, it will be in the order given)?
It seems likely that this is so but I'm not sure.
David Linn
BITNET: linndr@vuengvax
INTERNET(new): linndr@vuengvax.vanderbilt.edu
INTERNET(old): linndr%vuengvax.bitnet@wiscvm.wisc.arpa
UUCP: ...!uunet!vuse!drl
∂17-Nov-87 2227 Common-Lisp-mailer Implementation Questions
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 17 Nov 87 22:27:31 PST
Return-Path: <@Think.COM:barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 18 Nov 87 01:26:46 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 18 Nov 87 01:26:42 EST
Date: Wed, 18 Nov 87 01:27 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Implementation Questions
To: LINNDR%VUENGVAX.BITNET@forsythe.stanford.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8711180458.AA21295@Think.COM>
Message-Id: <871118012756.0.BARMAR@OCCAM.THINK.COM>
Date: Tue, 17 Nov 87 22:55 CDT
From: <LINNDR%VUENGVAX.BITNET@forsythe.stanford.edu> (David Linn)
If defun is a macro, to what does it expand? My best guess would be
a (setf (symbol-function 'name) ...) based on the discussion of
symbol-function on page 90. My question then becomes: Into what
does the setf form expand? Is it intended that the update function
for symbol-value have an implmentation-dependent name?
↑↑↑↑↑↑↑↑↑↑↑↑
You meant SYMBOL-FUNCTION there, didn't you?
The same sort of question applies to the update function for
macro-function.
MOST update functions have implementation-dependent names. There are no
Common Lisp updaters for CAR, CDR, AREF, defstruct accessors, etc. The
only accessors I can think of offhand that have defined updaters are
SYMBOL-VALUE (the updater is SET), LDB (DPB), LOAD-BYTE (DEPOSIT-BYTE),
and CHAR-BIT (SET-CHAR-BIT).
2) LAMBDA-LISTS - Is the order of lambda-list keywords fixed? (p. 60)
Will the order alway be &optional/&rest/&key/&aux (meaning that
if the keyword is used, it will be in the order given)?
It seems likely that this is so but I'm not sure.
Since it doesn't say that they can be in any order, don't assume that
they can. I know some implementations are picky. The description shows
the order that is defined to be portable; if a program supplies them in
a different order then it "is an error".
I think there was a proposal in X3J13 regarding relaxing this somewhat,
but I'm not sure. On the other hand, perhaps the proposal was to make
the text explicit about the order requirement.
barmar
∂17-Nov-87 2356 Common-Lisp-mailer new address
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 17 Nov 87 23:56:19 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab06854; 18 Nov 87 2:50 EST
Received: from utokyo-relay by RELAY.CS.NET id ad13095; 18 Nov 87 2:48 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet)
id AA16866; Wed, 18 Nov 87 16:15:40 JST
Received: by titcca.cc.titech.junet (4.12/6.3Junet-BETA)
id AA26556; Wed, 18 Nov 87 16:10:00 jst
Return-Path: <yuasa@tutics.tut.junet>
Received: by nttlab.ntt.jp (4.12/6.2NTT.h) with TCP; Wed, 18 Nov 87 15:43:39 jst
Received: by tutics.tut.junet (ver3.3/6.2J/systemV)
id AA01704; Wed, 18 Nov 87 15:23:57 jst
Message-Id: <8711181523.AA01704@tutics.tut.junet>
Date: Wed, 18 Nov 87 15:23:57 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet%utokyo-relay.csnet@RELAY.CS.NET>
To: common-lisp@SAIL.STANFORD.EDU
Subject: new address
I recently moved to Toyohashi University of Technology, which is located
somewhere between Kyoto and Tokyo, Japan. My new mail address is
yuasa@tutics.tut.junet
from within Japan, and
yuasa%tutics.tut.junet%utokyo-relay.csnet@RELAY.CS.NET
from csnet in US.
Sincerely,
Taiichi Yuasa, Dr.
Lecturer
Department of Information and Computer Science
Toyohashi University of Technology
Tempaku-cho, Toyohashi, 440, Japan
tel: 0532-47-0111 ext 503
∂19-Nov-87 0959 Common-Lisp-mailer assoc question
Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 19 Nov 87 09:58:56 PST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
id AA26105; Thu, 19 Nov 87 10:01:43 PST
Received: by lcuxle.UUCP (4.6/4.2)
id AA27647; Thu, 19 Nov 87 10:41:03 EST
Date: Thu, 19 Nov 87 10:41:03 EST
From: vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia)
Message-Id: <8711191541.AA27647@lcuxle.UUCP>
To: common-lisp@sail.stanford.edu
Subject: assoc question
I don't know if this was discussed before, so please excuse the possible
repetition. According to CLtL (pp 279-281), assoc permits the keyword
:key, but neither assoc-if nor assoc-if-not allow it (same for rassoc,
rassoc-if, and rassoc-if-not). Franz Common Lisp and Xerox Common Lisp
follow the book and permit :key for just assoc (and rassoc), while KCL and
TI Explorer don't allow :key at all.
I think it should not be allowed at all since assoc lists are defined
as pairs such that the keys are the cars of the respective pairs, not
some function of the respective cars. In any event, there should certainly
not be an inconsistency.
Elia Weixelbaum
∂19-Nov-87 1116 Common-Lisp-mailer assoc question
Received: from [128.81.41.234] by SAIL.STANFORD.EDU with TCP; 19 Nov 87 11:16:26 PST
Received: from SWAN.SCRC.Symbolics.COM by MEAD.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 112217; Thu 19-Nov-87 14:02:22 EST
Date: Thu, 19 Nov 87 14:01 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: assoc question
To: Weixelbaum Elia <vax135!lcuxle!elia@ucbvax.Berkeley.EDU>, common-lisp@sail.stanford.edu
In-Reply-To: <8711191541.AA27647@lcuxle.UUCP>
Message-ID: <19871119190135.5.DCP@SWAN.SCRC.Symbolics.COM>
Date: Thu, 19 Nov 87 10:41:03 EST
From: vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia)
...
I think it should not be allowed at all since assoc lists are defined
as pairs such that the keys are the cars of the respective pairs, not
some function of the respective cars. In any event, there should certainly
not be an inconsistency.
I think this is because an "Association list" is poorly defined. It
appears to be historically defined. A better definition of the CLtL'84
intent might be that the car /contains/ the key of the association, and
by default the car /is/ the key of the association.
I agree it does appear to be inconsistent (with FIND, COUNT and
POSITION) that ASSOC-IF doesn't take a :KEY argument.
∂19-Nov-87 1310 Common-Lisp-mailer assoc question
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Nov 87 13:09:54 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 284243; Thu 19-Nov-87 15:10:25 EST
Date: Thu, 19 Nov 87 15:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: assoc question
To: Weixelbaum Elia <vax135!lcuxle!elia@ucbvax.Berkeley.EDU>
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8711191541.AA27647@lcuxle.UUCP>
Message-ID: <19871119201019.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 19 Nov 87 10:41:03 EST
From: vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia)
According to CLtL (pp 279-281), assoc permits the keyword
:key, but neither assoc-if nor assoc-if-not allow it (same for rassoc,
rassoc-if, and rassoc-if-not).
The Cleanup subcommittee of X3J13 has addressed this issue, but apparently
it's on hold right now while higher priority things are attended to, although
the proposal really just needs some editorial work before it's presented to
X3J13.
My own opinion is that the -if and -if-not ones should take keys also.
∂20-Nov-87 1429 Common-Lisp-mailer Re: assoc question
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 87 14:29:22 PST
Received: from RTS-12.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 20 Nov 87 17:22-EST
Message-Id: <2773434123-6011396@RTS-12>
Sender: cerys@RTS-12
Date: Fri, 20 Nov 87 17:22:03 EST
From: "Daniel L. Cerys" <Cerys@XX.LCS.MIT.EDU>
To: vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia)
Cc: common-lisp@sail.stanford.edu
Subject: Re: assoc question
In-Reply-To: Msg of Thu, 19 Nov 87 10:41:03 EST from vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia)
> Franz Common Lisp and Xerox Common Lisp
> follow the book and permit :key for just assoc (and rassoc), while KCL and
> TI Explorer don't allow :key at all.
On your Explorer, you are probably either using Zetalisp or you are
running with very old software (Release 2). The Common-Lisp ASSOC
in Release 3.0 of the Explorer follows CLtL and allows for a :KEY arg.
> In any event, there should certainly
> not be an inconsistency.
I agree, but I think all of the ASSOC functions should accept a :KEY
arg. Alists are commonly used in Lisp. Of the following, the ASSOC-IF
version is much easier to read.
;;ALIST is an alist where the CAR's are objects (eg persons)
(assoc-if #'over-the-hill-p alist :key #'age)
(find-if #'over-the-hill-p alist :key #'(lambda (x) (age (car x))))
Since alists are in common use, and it would make the ASSOC functions
consistent with FIND et al, the ASSOC functions should also accept :KEY
args.
∂24-Nov-87 1340 Common-Lisp-mailer changing the value of *package* within a load?
Received: from AI.WISC.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 87 13:40:00 PST
Date: Tue, 24 Nov 87 15:39:43 CST
From: neves@cs.wisc.edu (David M. Neves)
Message-Id: <8711242139.AA12265@ai.wisc.edu>
Received: by ai.wisc.edu; Tue, 24 Nov 87 15:39:43 CST
To: common-lisp@sail.stanford.edu
Cc: neves@cs.wisc.edu
Subject: changing the value of *package* within a load?
When our students log into one of our Lisp Machines (Xerox 1108s) an
init file is loaded that initializes certain things for them. One of
the things I would like the init file to set is the value of
*package*. Unfortunately the load function protects *package* and
reinstates the value it had before load was called. Is there any way
(even a kludge) that I can permanently change the value of *package*
when a file is being loaded with load?
(I realize that one solution is to code my own version of load that
doesn't save away *package*.)
-Thanks, David
∂29-Nov-87 2253 Common-Lisp-mailer List membership?
Received: from CAEN.ENGIN.UMICH.EDU by SAIL.STANFORD.EDU with TCP; 29 Nov 87 22:52:55 PST
Received: by caen.engin.umich.edu (5.54/umix-2.0)
id AA03082; Mon, 30 Nov 87 01:39:01 EST
Date: Mon, 30 Nov 87 01:39:01 EST
From: conliffe@caen.engin.umich.edu (darryl c conliffe)
Message-Id: <8711300639.AA03082@caen.engin.umich.edu>
To: Common-Lisp@SAIL.Stanford.Edu
Subject: List membership?
I am interested - what news is here?
- Darryl C. Conliffe
∂01-Dec-87 1628 Common-Lisp-mailer Forwarding Dr. Ito's message.
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 87 16:28:34 PST
Date: Tue, 01 Dec 87 16:16:13 PST
From: Thom Linden <baggins@ibm.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
cc: "Robert F. Mathis" <mathis@c.isi.edu>,
"Christian Queinnec" <mcvax!inria!queinnec@seismo.css.gov>,
"Jerome Chailloux" <mcvax!inria!chaillou@seismo.css.gov>,
"Takayasu Ito" <tito%aoba.aoba.tohoku.junet@relay.cs.net>
Message-ID: <871201.161613.baggins@IBM.com>
Subject: Forwarding Dr. Ito's message.
I have used tito@aoba.aoba.tohoku.junet successfully.
Regards,
Thom
===================================================================
Received: from UTOKYO-RELAY.CSNET by IBM.COM on 11/28/87 at 09:32:05 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa14879; 26 Nov 87 15:56 EST
Received: from utokyo-relay by RELAY.CS.NET id ab10972; 26 Nov 87 15:46 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0)
id AA10791; Thu, 26 Nov 87 23:16:09 JST
Received: by nttlab.ntt.jp (4.12/6.2NTT.h) with TCP; Thu, 26 Nov 87 22:32:57 jst
Received: by aoba.aoba.tohoku.junet (4.12/6.3Junet-1.0); Thu, 26 Nov 87 21:45:22 jst
Received: by ito.aoba.tohoku.junet (4.12/6.3Junet-1.0)
id AA00161; Thu, 26 Nov 87 19:18:16 jst
Date: Thu, 26 Nov 87 19:18:16 jst
From: Takayasu ITO <ito%ito.aoba.tohoku.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <ito@ito.aoba.tohoku.junet>
Message-Id: <8711261018.AA00161@ito.aoba.tohoku.junet>
To: BAGGINS%ibm.com%relay.cs.net%u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: Test
Dear Dr. Linden,
I have several mail addresses:
ito@aoba.aoba.tohoku.junet,which is my major and original e-mail address;
tito@aoba.aoba.tohoku.junet,which has been opened to receive the news and
information on Lisp Standardization;
{chairlisp/chairlsp}@nttlab.ntt.junet,which has been opened to receive any
information on Lisp Standardization,addressed
to the Japanese chairman on the matter,but it
has found recently that this mail address can
not accessible from abroad.
{Sorry! I made some confusions}.
This address works in Japan,and all mails receivee
by this address will be automatically sent to the
above "tito@aoba.aoba.tohoku.junet"
Also I cannot send my mails through "kddlab",but I can reply for the mails from
"csnet-relay.csnet@u-tokyo.junet" in most cases,finding a route from my station.
I appreciate if you would kindly distribute this information to your people in
ANSI CommonLisp Committee and Drs. Queinnec and Chailloux (who sent several
e-mails through kddlabs to me).
Thanking in advance.
Best regards, Poor E-mailer
Takayasu Ito(ito@aoba.aoba.tohoku.junet)
∂03-Dec-87 1912 Common-Lisp-mailer Open House at IBUKI
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 19:12:24 PST
Received: by labrea.stanford.edu; Thu, 3 Dec 87 19:07:33 PST
Received: by ibuki.UUCP (5.52/4.7)
id AA03397; Thu, 3 Dec 87 17:50:07 PST
Date: Thu, 3 Dec 87 17:50:07 PST
From: ibuki!rww@labrea.stanford.edu (Richard Weyhrauch)
Message-Id: <8712040150.AA03397@ibuki.UUCP>
To: common-lisp@sail.Stanford.EDU
Subject: Open House at IBUKI
OPEN HOUSE IBUKI OPEN HOUSE IBUKI OPEN HOUSE IBUKI OPEN HOUSE
IBUKI invites you to an OPEN HOUSE featuring: FOOD, FUN and ENTERTAINMENT.
TIME: Monday, December 14
6:00 PM til ...
AT: IBUKI
1447 Stierlin Road
Mountain View, CA 94043
Further details: Phone (415) 961-4996.
Join in celebrating our NEW LOCATION and the new release of IBUKI Common Lisp
∂04-Dec-87 1505 Common-Lisp-mailer Symbolics DRIBBLE compatibility?
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 4 Dec 87 15:05:24 PST
Return-Path: <@occam.think.com:barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 4 Dec 87 17:42:22 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 4 Dec 87 17:42:18 EST
Date: Fri, 4 Dec 87 17:43 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Symbolics DRIBBLE compatibility?
To: common-lisp@sail.stanford.edu
Cc: customer-reports@symbolics.com
Message-Id: <871204174325.0.BARMAR@OCCAM.THINK.COM>
I am wondering about the compatibility of Symbolics's implementation of
DRIBBLE with CLtL. According to the Symbolics documentation (page 680
of Volume 2A of the Encyclopedia Symbolicorum), they believe that they
are compatible.
The way the Symbolics (DRIBBLE pathname) works is that it binds
*STANDRD-INPUT, *STANDARD-OUTPUT*, etc. to the dribble stream and then
calls the Lisp read-eval-print loop. It also sets up a catch-tag.
(DRIBBLE) throws to the tag, and appropriate unwind-protects close the
dribble stream.
What does this mean as far as compatibility is concerned? Consider the
following form:
(progn (dribble "filename")
(print 'foo)
(dribble))
From reading CLtL one would assume that this would print put FOO into
the file. On a Symbolics system the first DRIBBLE starts recording I/O
and then goes to a new r-e-p loop; the PRINT doesn't get executed until
the user does (dribble), and then the second DRIBBLE complains that
output isn't being recorded.
Or how about typing:
(dribble "filename)
(progn (print 'foo)
(dribble)
(print 'bar))
The second PRINT will never get executed, because the (dribble) throws
out of the PROGN.
Finally, you could really get screwed if you start dribbling, do
something that gets you into the debugger, and decide to stop dribbling;
you will lose your debugger session. This doesn't actually happen
because Symbolics disables dribbling when you go into the debugger or
when you get a new r-e-p loop with the Suspend key, so (dribble) just
says that output isn't being recorded and does nothing else. (The fact
that debugger and break loop I/O isn't dribbled is another point of
contention I have.)
CLtL doesn't say a whole lot about DRIBBLE. In particular, it doesn't
say what the return value is, but that doesn't mean that it is allowed
for (dribble) not to return, does it? What do other Common Lispers
think?
barmar
∂07-Dec-87 0945 RPG My E-mail address in Japan
∂04-Dec-87 2202 OKUNO@SUMEX-AIM.Stanford.EDU My E-mail address in Japan
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87 22:01:55 PST
Date: Fri, 4 Dec 87 22:00:45 PST
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.Stanford.EDU>
Subject: My E-mail address in Japan
To: aap@SUMEX-AIM.Stanford.EDU
cc: crispin@SUMEX-AIM.Stanford.EDU
Organization: Knowledge Systems Laboratory, CSD, Stanford University
Group: Heuristic Programming Project
Project: Advanced Architectures Project
Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703
Phone: +1 (415)725-4854
Message-ID: <12355960969.15.OKUNO@SUMEX-AIM.Stanford.EDU>
I'm back from Colorado Springs and will leave for Japan tommorow morning.
You can reach me in Japan by E-mail. My address is
from sumex,
okuno@ntt-20 (a direct link between sumex and ntt-20)
okuno@ntt-20.ntt.jp (a direct link)
okuno@ntt-20.ntt.jp.#internet (via CSNET)
and from other sites
okuno%ntt-20.ntt.jp@relay.cs.net
Thanks,
- Gitchang -
-------
∂07-Dec-87 1427 Common-Lisp-mailer Fill pointers and ADJUST-ARRAY
Received: from NSS.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 7 Dec 87 14:27:17 PST
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa12537; 7 Dec 87 22:19 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Mon, 7 Dec 87 22:15:45 GMT
Message-Id: <20024.8712072215@aiva.ed.ac.uk>
To: common-lisp@sail.stanford.edu,
kcl <@sally.utexas.edu:kcl@rascal.ics.utexas.edu>
Subject: Fill pointers and ADJUST-ARRAY
Apologies if this has been discussed before...
The description of ADJUST-ARRAY on pp. 297-8 of CLtL does not say
what happens to a fill pointer when ADJUST-ARRAY is called without
a :FILL-POINTER parameter. I expected the fill pointer to remain
as it was, but this is not what happens in KCL:
staffa 18% kcl
KCl (Kyoto Common Lisp) June 3, 1987
>(setq v (make-array 0 :fill-pointer 0 :adjustable t))
#()
>(adjust-array v 2)
#(NIL NIL)
>(fill-pointer v)
Error: The vector #(NIL NIL) has no fill pointer.
Error signalled by FILL-POINTER.
Is KCl's behavior incorrect?
What should happen if an array is adjusted to a size smaller than its
fill pointer?
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂07-Dec-87 2315 Common-Lisp-mailer structure type specifier
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:15:01 PST
Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 79449; Mon 7-Dec-87 22:23:45 EST
Date: Mon, 7 Dec 87 22:23 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: structure type specifier
To: Common-Lisp@sail.stanford.edu
Message-ID: <871207222343.9.CFRY@JONES.AI.MIT.EDU>
STRUCTURE is not a legal type specifier according to
CLtL p 43 table of type specifier symbols.
Seems awfully useful & natural to me.
Has CLtL been superceded? Did I miss some reference somewhere?
Similarly STRUCTUREP isn't a CL function.
Does anyone have a CL implementation without structurep or equivalent?
∂08-Dec-87 0354 Common-Lisp-mailer structure type specifier
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87 03:53:59 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 303407; Tue 8-Dec-87 06:53:54 EST
Date: Tue, 8 Dec 87 06:53 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: structure type specifier
To: Christopher Fry <cfry@OZ.AI.MIT.EDU>
cc: Common-Lisp@sail.stanford.edu
In-Reply-To: <871207222343.9.CFRY@JONES.AI.MIT.EDU>
Message-ID: <19871208115346.0.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Mon, 7 Dec 87 22:23 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
STRUCTURE is not a legal type specifier according to
CLtL p 43 table of type specifier symbols.
Seems awfully useful & natural to me.
Has CLtL been superceded? Did I miss some reference somewhere?
Similarly STRUCTUREP isn't a CL function.
Does anyone have a CL implementation without structurep or equivalent?
Actually, it doesn't seem "awfully useful & natural" to me.
Natural, yes, but since CLtL doesn't have any primitives
for dealing with structures at all, it doesn't seem incredibly
useful.
But that's the fault of CL, and not your idea. Symbolics CL
provides NAMED-STRUCTURE-P and the STRUCTURE type. Types
created by DEFSTRUCT are all subtypes of STRUCTURE.
If you know where to find them, there are also tools for decoding a
structure.
∂08-Dec-87 0418 Common-Lisp-mailer Re: Fill pointers and ADJUST-ARRAY
Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 04:18:08 PST
Received: by RUTGERS.EDU (5.54/1.14) with UUCP
id AA00209; Tue, 8 Dec 87 00:59:07 EST
Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424)
id AA15904; Mon, 7 Dec 87 21:41:14 PST
Received: by pyrnova.pyramid.COM (5.51/OSx4.0b-870424)
id AA20796; Mon, 7 Dec 87 21:40:43 PST
Date: 7 Dec 1987 21:11-PST
From: David Bein <pyrnj!pyramid!bein@RUTGERS.EDU>
Subject: Re: Fill pointers and ADJUST-ARRAY
To: common-lisp@sail.stanford.edu@RUTGERS.EDU
Message-Id: <565938713/bein@pyrnova>
[ This is in reply to Jeff Dalton's message. The mail system dropped my
last letter to him off into never-never land.]
It would appear that KCL interprets the lack of a :FILL-POINTER
argument to mean that the resulting vector should not have a
fill-pointer. Even though CLtL only mentions what happens when
:FILL-POINTER is supplied to ADJUST-ARRAY, it seems silly that
the resulting vector does not have a fill-pointer when the original one
did. In this regard I think KCL needs to be fixed.
I sent a letter some time back to the mailing list questioning what
the behavior should be if :FILL-POINTER is not specified. Nobody
spoke up, so I'll make my suggestion again. The answer to your
second question (adjusted array being smaller than its current
fill-pointer) is answered in #1 and #2:
I think ADJUST-ARRAY should have the following semantics for its
:FILL-POINTER argument:
(1) If :FILL-POINTER is NIL or not supplied, it defaults to the
current value of the vector's fill-pointer.
(2) If :FILL-POINTER is T, then the fill-pointer is set to the
minimum of its current value or the length of the resulting
vector.
(3) Otherwise, :FILL-POINTER should be a non-negative integer less than
or equal to the size of the resulting array.
In all cases, an error occurs if the final value of the fill-pointer
is out of bounds.
∂08-Dec-87 0648 Common-Lisp-mailer Re: structure type specifier
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 06:48:11 PST
Received: from BYRD.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 25378; Tue 8-Dec-87 09:48:15 EST
Message-Id: <2774962087-99174@BYRD>
Sender: baldwin@BYRD
Date: Tue, 8 Dec 87 09:48:07 EST
Reply-To: baldwin@cs.rochester.edu
From: baldwin@ACORN
To: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics.COM>
Cc: common-lisp@sail.stanford.edu
Subject: Re: structure type specifier
In-Reply-To: Msg of Tue, 8 Dec 87 06:53 EST from Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
STRUCTURE is not a legal type specifier ....
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Actually, it doesn't seem "awfully useful & natural" to me.
Natural, yes, but since CLtL doesn't have any primitives
for dealing with structures at all, it doesn't seem incredibly
useful.
Well, I think a standardized way of testing for "structure-hood"
would be quite useful - from time to time I write my own tools for
things like pretty-printing, inspecting complex data structures, etc.
(yes, most implementations have some or all of these, but the tools
aren't standard across implementations, so for portability or to fill
in the gaps in some implementation I sometimes write my own.) I also
tend to write code that uses structures heavily, so my tools have to
deal with them. In all of my tools I continually find myself wanting to
find out if an argument is a structure precisely BECAUSE Common Lisp
doesn't provide primitives for getting inside a structure - knowing
that something is a structure then tells the printer/inspector/etc
that it has to punt (e.g., hope the user provided a decent
:print-function, or something like that). Conversely, of course,
if Common Lisp DID provide generic structure-manipulating primitives then
I would want to test for "structure-hood" in order to be able to
decide whether those primitives could be applied to an object.
In either case I think Common Lisp should provide a "structurep"
predicate, "structure" as a type identifier, etc.
∂08-Dec-87 1621 Common-Lisp-mailer Re: structure type specifier
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 16:21:14 PST
Received: from Riesling.ms by ArpaGateway.ms ; 08 DEC 87 16:21:02 PST
Sender: "Larry_Masinter.PARC"@Xerox.COM
Date: 8 Dec 87 16:20:16 PST (Tuesday)
Subject: Re: structure type specifier
From: "Larry_Masinter.PARC"@Xerox.COM
To: cfry@OZ.AI.MIT.EDU
cc: Common-Lisp@sail.stanford.EDU
In-Reply-to: cfry%OZ.AI.MIT:EDU:Xerox's message of 7 Dec 87 23:40
Message-ID: <871208-162102-5563@Xerox>
Its legit and even good design practice to treat every data type as if it might
be a structure. If Xerox Common Lisp had STRUCTUREP, it would be true of every
object. (Of course, some objects, like fixnums, don't have slots and are
"preallocated".)
∂08-Dec-87 1630 Common-Lisp-mailer Re: structure type specifier
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 16:28:41 PST
Return-Path: <@Think.COM:barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 8 Dec 87 19:23:49 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 8 Dec 87 19:22:21 EST
Date: Tue, 8 Dec 87 19:23 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: structure type specifier
To: baldwin@cs.rochester.edu
Cc: Robert W. Kerns <RWK@yukon.scrc.symbolics.com>,
common-lisp@sail.stanford.edu
In-Reply-To: <2774962087-99174@BYRD>
Message-Id: <871208192313.6.BARMAR@OCCAM.THINK.COM>
Date: Tue, 8 Dec 87 09:48:07 EST
From: baldwin@ACORN
In all of my tools I continually find myself wanting to
find out if an argument is a structure precisely BECAUSE Common Lisp
doesn't provide primitives for getting inside a structure - knowing
that something is a structure then tells the printer/inspector/etc
that it has to punt (e.g., hope the user provided a decent
:print-function, or something like that).
Presumably your tools also have to punt if the object is of a type not
mentioned at all in CLtL (e.g. a flavor). So the structure case could
be handled by the T clause in your TYPECASE. Unless it can do something
different with structures than it does with other undecipherable
objects there doesn't seem to be a need for a way to distinguish them.
barmar
∂09-Dec-87 0635 Common-Lisp-mailer Re: structure type specifier
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87 06:34:55 PST
Received: from BYRD.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 25478; Wed 9-Dec-87 09:36:30 EST
Message-Id: <2775047786-60842@BYRD>
Sender: baldwin@BYRD
Date: Wed, 9 Dec 87 09:36:26 EST
Reply-To: baldwin@cs.rochester.edu
From: baldwin@ACORN
To: common-lisp@sail.stanford.edu
Subject: Re: structure type specifier
In-Reply-To: Msg of Tue, 8 Dec 87 19:23 EST from Barry Margolin <barmar@Think.COM>
Presumably your tools also have to punt if the object is of a type not
mentioned at all in CLtL (e.g. a flavor)....
Problem is that things not mentioned at all in CLtL are necessarily
implementation-dependent and so I have an "honest" choice between
compromising portability for clear handling of these objects or not,
whereas with structures I don't have this choice - they're a standard
part of Common Lisp, but Common Lisp doesn't give me the tools to
do much with them. (Put another way, if I want to handle an
implementation-dependent extension to Common Lisp in an
implementation-dependent way I don't feel as bad about it as handling
a defined part of the language in a non-portable way.) For this reason
I still think Common Lisp badly needs at least minimal support a
"structure" type.
∂09-Dec-87 1125 Common-Lisp-mailer Re: structure type specifier
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 9 Dec 87 11:24:58 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 304367; Wed 9-Dec-87 13:49:33 EST
Date: Wed, 9 Dec 87 13:49 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: structure type specifier
To: baldwin@cs.rochester.edu
cc: common-lisp@sail.stanford.edu
In-Reply-To: <2775047786-60842@BYRD>
Message-ID: <19871209184929.0.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Wed, 9 Dec 87 09:36:26 EST
From: baldwin@ACORN
Problem is that things not mentioned at all in CLtL are necessarily
implementation-dependent and so I have an "honest" choice between
compromising portability for clear handling of these objects or not,
whereas with structures I don't have this choice - they're a standard
part of Common Lisp, but Common Lisp doesn't give me the tools to
do much with them. (Put another way, if I want to handle an
implementation-dependent extension to Common Lisp in an
implementation-dependent way I don't feel as bad about it as handling
a defined part of the language in a non-portable way.) For this reason
I still think Common Lisp badly needs at least minimal support a
"structure" type.
I don't disagree, I'm just pointing out that it's not worth
much unless we also include minimal support for working with
objects of the STRUCTURE type. Neither you nor I are the first
to point this out.
∂10-Dec-87 1243 Common-Lisp-mailer please add us to Common Lisp
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Dec 87 12:42:55 PST
Received: from relay2.cs.net by RELAY.CS.NET id an20901; 10 Dec 87 15:10 EST
Received: from ubc by RELAY.CS.NET id af07212; 10 Dec 87 14:52 EST
Received: by ubc.csnet id AA01930; Thu, 10 Dec 87 10:45:39 pst
Date: 10 Dec 87 10:45 -0800
From: list-request%ubc.csnet@RELAY.CS.NET
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Sender: Marilyn Martin <martin%ubc.csnet@RELAY.CS.NET>
To: Common-Lisp@SAIL.STANFORD.EDU
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <1189*martin@ean.ubc.cdn>
Subject: please add us to Common Lisp
Subject: please add us to Common Lisp
Can you please add the address
common-lisp%ubc.csnet@relay.cs.net
to the Common Lisp list? We would like to redistribute the list to the
Canadian research network CDNnet.
Also, you may get requests to join the list directly from CDNnet
users. If it is easy to record somewhere, can you direct those
requests to me? The addresses will probably look like
user%subdomain.cdn%ubc.csnet@relay.cs.net
If you already have CDNnet users on the list, I'd be glad to take over
the redistribution to them from here.
Thanks,
Marilyn Martin
University of British Columbia
list-request@ubc.csnet
list-request%ubc.csnet@relay.cs.net
∂10-Dec-87 2214 Common-Lisp-mailer Question about declaration
Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 10 Dec 87 22:14:20 PST
Date: Fri, 11 Dec 87 01:16 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Question about declaration
To: CL@ACORN.CS.ROCHESTER.EDU
Message-ID: <871211011624.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Default-Character-Style: (:FIX :CONDENSED :NORMAL)
Fonts: CPTFONTC
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: 401A CS Building, Computer Science Department, University of Rochester, Rochester NY 14627
Phone: 716-275-1118
How would you write a function declaration for the following?
(defun foo (bar)
(declare (type list bar))
(values-list bar)
(proclaim '(function foo (list) ????))
Brad Miller
------
miller@cs.rochester.edu {...allegra!rochester!miller}
Brad Miller
University of Rochester Computer Science Department
∂11-Dec-87 0227 Common-Lisp-mailer Re: Question about declaration
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 02:27:49 PST
Received: from jabbah.cs.rochester.edu (JABBAH.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 25625; 11 Dec 87 05:29:06 EST
Received: from loopback by jabbah.cs.rochester.edu (3.2/h) id AA00767; Fri, 11 Dec 87 05:27:19 EST
Message-Id: <8712111027.AA00767@jabbah.cs.rochester.edu>
To: miller@cs.rochester.edu
Cc: CL@ACORN.CS.ROCHESTER.EDU
Subject: Re: Question about declaration
In-Reply-To: Your message of Fri, 11 Dec 87 01:16:00 -0500.
<871211011624.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Date: Fri, 11 Dec 87 05:27:16 -0500
From: quiroz
If (as it seems) `bar' isn't restricted to be anything sharper than
`list', then the only thing we know is that `foo' returns multiple
values. (Indeed, `foo' is just another name for `values-list', but
I assume you are just abstracting here the useful aspects of a real
`foo' of yours.)
I suspect I would write something as uninformative as
(proclaim '(function foo (list) (values &rest list)))
which is marginally better than no declaration at all.
While at this, how do you use the &-markers in a `values' specifier?
For instance, the only things I believe make sense after &rest in a
`values' specifier should be `null' (utterly useless) or `list'
(quite uninformative). Anything more general than `list' would
admit of impossible trash, anything disjoint with list is
unspeakable. Yet, KCL just let me try `...&rest float'. Better not
think what a compiler could do with such.
=Cesar
--------
Cesar Augusto Quiroz Gonzalez
Department of Computer Science ...allegra!rochester!quiroz
University of Rochester or
Rochester, NY 14627 quiroz@cs.rochester.edu
∂11-Dec-87 0800 Common-Lisp-mailer Re: Question about declaration
Received: from [8.2.0.18] by SAIL.STANFORD.EDU with TCP; 11 Dec 87 08:00:25 PST
Date: 11 Dec 1987 11:01-EST
Sender: NGALL@G.BBN.COM
Subject: Re: Question about declaration
From: NGALL@G.BBN.COM
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <[G.BBN.COM]11-Dec-87 11:01:23.NGALL>
In-Reply-To: <8712111027.AA00767@jabbah.cs.rochester.edu>
Date: Fri, 11 Dec 87 05:27:16 -0500
From: quiroz
...
I suspect I would write something as uninformative as
(proclaim '(function foo (list) (values &rest list)))
which is marginally better than no declaration at all.
While at this, how do you use the &-markers in a `values' specifier?
For instance, the only things I believe make sense after &rest in a
`values' specifier should be `null' (utterly useless) or `list'
(quite uninformative). Anything more general than `list' would
admit of impossible trash, anything disjoint with list is
unspeakable. Yet, KCL just let me try `...&rest float'. Better not
think what a compiler could do with such.
=Cesar
I think the type specifier for the function FOO is supposed to be
(PROCLAIM '(FUNCTION FOO (LIST) (VALUES &REST T))
This is because the type specifier following &REST is supposed to declare
the type of all the remaining arguments/values. You won't find this in CLtL,
but I have it marked in my copy as a proposed clarification in Guy Steele's
list.
If this is NOT the behavior of &REST, then all &REST could tell a
compiler/programmer is that this function can take/return any number
of arguments (depending on where &REST is used).
-- Nick
∂11-Dec-87 0850 Common-Lisp-mailer Re: Question about declaration
Received: from CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 08:50:51 PST
Received: by cayuga.cs.rochester.edu (5.52/h) id AA24809; Fri, 11 Dec 87 11:50:29 EST
Received: from loopback by furud.cs.rochester.edu (3.2/h) id AA00350; Fri, 11 Dec 87 11:50:24 EST
Message-Id: <8712111650.AA00350@furud.cs.rochester.edu>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Re: Question about declaration
In-Reply-To: Your message of 11 Dec 87 11:01:00 -0500.
<[G.BBN.COM]11-Dec-87 11:01:23.NGALL>
Date: Fri, 11 Dec 87 11:50:20 -0500
From: quiroz@cs.rochester.edu
| I think the type specifier for the function FOO is supposed to be
| (PROCLAIM '(FUNCTION FOO (LIST) (VALUES &REST T))
| This is because the type specifier following &REST is supposed to declare
| the type of all the remaining arguments/values. You won't find this in CLtL,
| but I have it marked in my copy as a proposed clarification in Guy Steele's
| list.
The clarification would be most valuable. As it stands now, I read
your declaration as saying `... and the type of the &REST argument
is T', when we probably want to say `... list of T', although the
latter cannot be uttered in the type calculus of Common Lisp.
I remember there used to be a file ftpable from somewhere, which
contained authoritative errata and clarifications. Does it still
exist?
=Cesar
--------
Cesar Augusto Quiroz Gonzalez
Department of Computer Science ...allegra!rochester!quiroz
University of Rochester or
Rochester, NY 14627 quiroz@cs.rochester.edu
∂11-Dec-87 1211 Common-Lisp-mailer Re: Question about declaration
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 12:11:35 PST
Received: from DOUGHNUT.CS.ROCHESTER.EDU (DOUGHNUT.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 25734; 11 Dec 87 15:13:28 EST
Date: Fri, 11 Dec 87 15:13 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Re: Question about declaration
To: quiroz@ACORN.CS.ROCHESTER.EDU
cc: CL@ACORN.CS.ROCHESTER.EDU
In-Reply-To: <8712111027.AA00767@jabbah.cs.rochester.edu>
Message-ID: <871211151322.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Default-Character-Style: (:FIX :CONDENSED :NORMAL)
Fonts: CPTFONTC
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: 401A CS Building, Computer Science Department, University of Rochester, Rochester NY 14627
Phone: 716-275-1118
Date: Fri, 11 Dec 87 05:27:16 -0500
From: quiroz
If (as it seems) `bar' isn't restricted to be anything sharper than
`list', then the only thing we know is that `foo' returns multiple
values. (Indeed, `foo' is just another name for `values-list', but
I assume you are just abstracting here the useful aspects of a real
`foo' of yours.)
T
I suspect I would write something as uninformative as
(proclaim '(function foo (list) (values &rest list)))
which is marginally better than no declaration at all.
Are &markers accepted in these definitions? They aren't lamda lists. I
didn's see anything in CLtL to indicate that they are acceptible...
Thnx,
Brad
------
miller@cs.rochester.edu {...allegra!rochester!miller}
Brad Miller
University of Rochester Computer Science Department
∂12-Dec-87 0032 Common-Lisp-mailer ε1Question about declarationε0
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 22:22:17 PST
Received: from cayuga.cs.rochester.edu (CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 25769; 12 Dec 87 01:24:07 EST
Received: by cayuga.cs.rochester.edu (5.52/h) id AA27119; Sat, 12 Dec 87 01:21:53 EST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 305552; Fri 11-Dec-87 10:54:16 EST
Date: Fri, 11 Dec 87 10:54 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: ε1Question about declarationε0
To: miller@cs.rochester.edu
Cc: CL@ACORN.CS.ROCHESTER.EDU
In-Reply-To: <871211011624.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Message-Id: <19871211155410.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Character-Type-Mappings: (1 0 (NIL 0) (NIL :CONDENSED NIL) "CPTFONTC")
Fonts: CPTFONT, CPTFONTC
Date: Fri, 11 Dec 87 01:16 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
ε1 How would you write a function declaration for the following?
(defun foo (bar)
(declare (type list bar))
(values-list bar)
(proclaim '(function foo (list) ????))
ε0I wouldn't. CL doesn't have any syntax for declaring
a variable number of values, period.
∂12-Dec-87 0132 Common-Lisp-mailer Re: structure type specifier
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 12 Dec 87 01:31:58 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 305840; Fri 11-Dec-87 15:56:33 EST
Date: Fri, 11 Dec 87 15:56 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: structure type specifier
To: Larry_Masinter.PARC@Xerox.COM
cc: cfry@OZ.AI.MIT.EDU, Common-Lisp@sail.stanford.EDU
In-Reply-To: <871208-162102-5563@Xerox>
Message-ID: <19871211205618.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: 8 Dec 87 16:20:16 PST (Tuesday)
From: "Larry_Masinter.PARC"@Xerox.COM
Its legit and even good design practice to treat every data type as if it might
be a structure. If Xerox Common Lisp had STRUCTUREP, it would be true of every
object. (Of course, some objects, like fixnums, don't have slots and are
"preallocated".)
STRUCTURE (and STRUCTUREP) would just indicate whether they follow
the protocol of things you can to do **named structures**. (That is,
Inquiring about slots, acessing the slots found, and basically getting
your hands on the information in the original DEFSTRUCT). Since
fixna are neither defined nor definable as named structures, for them
to be STRUCTURE's would be a travesty.
I don't know just what YOU think the point of having such a type would
be if you're going to make Xerox Common Lisp have everything be a STRUCTURE.
Perhaps your point was really that some subtypes of COMMON may be implemented
as DEFSTRUCT's (for example, RANDOM-STATE is a good candidate).
∂12-Dec-87 0234 Common-Lisp-mailer string as vector of fixnums ?
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 12 Dec 87 02:34:17 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac17968; 12 Dec 87 2:55 EST
Received: from utokyo-relay by RELAY.CS.NET id ab16765; 12 Dec 87 2:47 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA12716; Sat, 12 Dec 87 16:26:29 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.3Junet-1.0)
id AA25820; Sat, 12 Dec 87 16:26:03+0900
Date: Sat, 12 Dec 87 16:26:03+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8712120726.AA25820@tansei.cc.u-tokyo.junet>
To: common-lisp@SAIL.STANFORD.EDU,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: string as vector of fixnums ?
A Question on the history;
When try to get a component of a string as a number, we must
get it as a character and then coerce it to number type.
I think it is ridiculous.
This situation attacked me several times when I wrote codes for
data conversion among lots of machines, deciding to conform Common Lisp 100%.
( historically, many dialects of Lisp can get a component of a string as
a number easily.
On symbolics, there are art-strings types, with which we can treat a character
of a string as number.)
I feel Common Lisp degrades as for the treatment of characters.
Or, there must be a decision on it I did not know.
Or, CLtL ignores this issue as an implementation-dependent thing.
Any opinions ? or I will appreciate if someone give me
the explanation for the process or the
history on the decision .
Thank you.
Masayuki Ida
∂12-Dec-87 1016 Common-Lisp-mailer string as vector of fixnums ?
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 12 Dec 87 02:34:17 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac17968; 12 Dec 87 2:55 EST
Received: from utokyo-relay by RELAY.CS.NET id ab16765; 12 Dec 87 2:47 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA12716; Sat, 12 Dec 87 16:26:29 JST
Received: by tansei.cc.u-tokyo.junet (4.12/6.3Junet-1.0)
id AA25820; Sat, 12 Dec 87 16:26:03+0900
Date: Sat, 12 Dec 87 16:26:03+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8712120726.AA25820@tansei.cc.u-tokyo.junet>
To: common-lisp@SAIL.STANFORD.EDU,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Subject: string as vector of fixnums ?
A Question on the history;
When try to get a component of a string as a number, we must
get it as a character and then coerce it to number type.
I think it is ridiculous.
This situation attacked me several times when I wrote codes for
data conversion among lots of machines, deciding to conform Common Lisp 100%.
( historically, many dialects of Lisp can get a component of a string as
a number easily.
On symbolics, there are art-strings types, with which we can treat a character
of a string as number.)
I feel Common Lisp degrades as for the treatment of characters.
Or, there must be a decision on it I did not know.
Or, CLtL ignores this issue as an implementation-dependent thing.
Any opinions ? or I will appreciate if someone give me
the explanation for the process or the
history on the decision .
Thank you.
Masayuki Ida
∂12-Dec-87 1215 Common-Lisp-mailer string as vector of fixnums ?
Received: from NSS.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 12 Dec 87 12:15:23 PST
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07983; 12 Dec 87 20:07 GMT
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Sat, 12 Dec 87 20:07:29 GMT
Message-Id: <27525.8712122007@aiva.ed.ac.uk>
To: common-lisp@sail.stanford.edu,
ida <@relay.cs.net,@utokyo-relay.csnet:ida@tansei.cc.u-tokyo.junet>
Subject: string as vector of fixnums ?
> Date: Sat, 12 Dec 87 16:26:03+0900
> From: Masayuki Ida
> A Question on the history;
> When try to get a component of a string as a number, we must
> get it as a character and then coerce it to number type.
> I think it is ridiculous.
The problem is that the numbers aren't portable but the characters are.
#\A is always #\A, but it isn't always 65. I believe Common Lisp does
not represent characters as numbers because it was trying for a more
abstract representation and to get away from the notion that each
character was a particular number.
I suspect it is relatively rare for anyone to want the number associated
with a character, and so requiring an extra step to get the number does
not seem so bad a thing.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂12-Dec-87 1723 Common-Lisp-mailer sloop
Received: from UUNET.UU.NET by SAIL.STANFORD.EDU with TCP; 12 Dec 87 17:23:36 PST
Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA18489; Sat, 12 Dec 87 20:23:27 EST
From: mcvax!jungfrau!ceb@uunet.UU.NET
Received: by mcvax.cwi.nl; Sun, 13 Dec 87 01:50:25 +0100 (MET)
Received: by cernvax.uucp (1.2/Ultrix2.0-B)
id AA19845; Sun, 13 Dec 87 01:32:49 +0100
Date: Sun, 13 Dec 87 01:32:49 +0100
Message-Id: <8712130032.AA19845@cernvax.uucp>
To: common-lisp@sail.stanford.edu
Subject: sloop
There was a recent brief mention in a mailing on this list of the existence
of a common-lisp loop macro called SLOOP.
Its existence is news to me, and I would be interested to find out
more about it, so if someone would mail me some specifics, I'd be
grateful. We currently use a home-grown CL loop macro here (mountain
grown?), and I'd really rather mainstream as soon as there is a stream
to main to.
Charles Buckley uucp: mcvax!ethz!ceb
earn: BUCKLEY@CZHETH5A
arpa: mcvax!ethz!ceb@uunet.uu.net
cb@sail.stanford.edu
Integrated Systems Laboratory
Federal Institute of Technology (ETH)
Zuerich, Switzerland
Postal Address:
Wiesgasse 9
CH-8304 Wallisellen
Tel: +411 256 52 45
∂13-Dec-87 1352 Common-Lisp-mailer ε1Question about declarationε0
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 13 Dec 87 13:52:33 PST
Received: from Think.COM (THINK.COM) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 25807; 13 Dec 87 16:53:04 EST
Return-Path: <mincy@Aquinas.Think.COM>
Received: from sauron.think.com by Think.COM; Sun, 13 Dec 87 16:06:07 EST
Received: from ZENO.THINK.COM by sauron.think.com; Sun, 13 Dec 87 16:06:01 EST
Date: Sun, 13 Dec 87 16:07 EST
From: Jeff Mincy <mincy@Think.COM>
Subject: ε1Question about declarationε0
To: RWK@yukon.scrc.symbolics.com, miller@cs.rochester.edu
Cc: CL@acorn.cs.rochester.edu
In-Reply-To: <19871211155410.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-Id: <871213160754.1.MINCY@ZENO.THINK.COM>
Character-Type-Mappings: (1 0 (NIL 0) (NIL :CONDENSED NIL) "CPTFONTC")
Fonts: CPTFONT, CPTFONTC
Date: Fri, 11 Dec 87 10:54 EST
From: Robert W. Kerns <RWK@yukon.scrc.symbolics.com>
Date: Fri, 11 Dec 87 01:16 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
ε1How would you write a function declaration for the following?
ε0 ε1(defun foo (bar)
ε0 ε1(declare (type list bar))
ε0 ε1(values-list bar)
ε0 ε1(proclaim '(function foo (list) ????))
ε0 I wouldn't. CL doesn't have any syntax for declaring
a variable number of values, period.
The &optional, &rest, and &key markers may appear in the value-type list
for the values type-specifier. p 48, CLtL.
The value-type for the function type-specifier may be a values type specifier.
p 47 CLtL
Therefore
One can say (function (number) (values number &optional float)),
to specify that a function returns a variable number of values.
But, It doesnt mean that anyone will listen to the declaration,
just because you can say it.
-jeff
∂14-Dec-87 0512 Common-Lisp-mailer string as vector of fixnums ?
Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 14 Dec 87 05:12:19 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 150334; Sat 12-Dec-87 17:09:44 EST
Date: Sat, 12 Dec 87 17:11 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: string as vector of fixnums ?
To: a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU,
ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
In-Reply-To: <8712120726.AA25820@tansei.cc.u-tokyo.junet>
Message-ID: <19871212221125.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Sat, 12 Dec 87 16:26:03+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
A Question on the history;
When try to get a component of a string as a number, we must
get it as a character and then coerce it to number type.
I think it is ridiculous.
There is more than one mapping from characters to integers. Some
computers use the ASCII code, others use the EBCDIC code, and around
the world I presume there must be other codes I've never heard of.
One reason for having character objects was so that programs could
be portable from one implementation of Common Lisp to another, even
if the two implementations used different character codes.
Another reason was so that character objects would have a recognizable
printed representation. Not many people are good at memorizing the
entire ASCII code, and it's even harder to memorize the longer codes
such as for Kanji characters.
∂14-Dec-87 0527 Common-Lisp-mailer string as vector of fixnums ?
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 14 Dec 87 05:27:03 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306383; Sat 12-Dec-87 18:13:15 EST
Date: Sat, 12 Dec 87 18:13 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: string as vector of fixnums ?
To: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
cc: common-lisp@SAIL.STANFORD.EDU, ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
In-Reply-To: <8712120726.AA25820@tansei.cc.u-tokyo.junet>
Message-ID: <19871212231315.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Sat, 12 Dec 87 16:26:03+0900
From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
A Question on the history;
When try to get a component of a string as a number, we must
get it as a character and then coerce it to number type.
I think it is ridiculous.
This situation attacked me several times when I wrote codes for
data conversion among lots of machines, deciding to conform Common Lisp 100%.
If you're doing code conversion, you probably don't want to be using
characters at all, but rather arrays of unsigned bytes. (I've often
said that the only way to write a portable file is with (UNSIGNED-BYTE 8)).
Consider reading a file of EBCDIC in a lisp which only supports 7-bit ascii
for its characters, for example. You could get errors or lose bits if you try
to read it into a string! (I doubt there are any implementations which only
store 7 bits in their strings, but they would be quite legitimate). Certainly,
many EBCDIC codes may be undefined values for characters in an ASCII lisp,
and the byte 65 is unlikely to really mean #\A in EBCDIC.
( historically, many dialects of Lisp can get a component of a string as
a number easily.
On symbolics, there are art-strings types, with which we can treat a character
of a string as number.)
This hasn't been true for a year. The types you describe were part of
old ZetaLisp, and do not exist in Release 7 at all.
I feel Common Lisp degrades as for the treatment of characters.
Or, there must be a decision on it I did not know.
Or, CLtL ignores this issue as an implementation-dependent thing.
I feel that what Common Lisp does here is exactly the right thing.
However, I believe CL needs to add facilities for specifying the external
coding of character files, as part of OPEN.
Any opinions ? or I will appreciate if someone give me
the explanation for the process or the
history on the decision .
Thank you.
Masayuki Ida
∂16-Dec-87 0132 Common-Lisp-mailer Current practice:argument types in function declarations
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Dec 87 01:32:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 DEC 87 01:32:19 PST
From: masinter.PA@Xerox.COM
Date: 16 Dec 87 1:32:02 PST
Subject: Current practice:argument types in function declarations
To: common-lisp@sail.stanford.edu
cc: masinter.PA@Xerox.COM
Message-ID: <871216-013219-2778@Xerox>
The cleanup committee is considering various issues surrounding function
declarations, and, in particular, declarations of the types of arguments.
We've had considerable input about what such declarations could mean, should
mean, what CLtL says they mean. Rather than going over all of that, this is a
question about current practice:
What do current implementations actually do? What do current users actually use
have in their programs?
Is anyone aware of any (released? supported?) Common Lisp implementation that
pays any attention at all to the types of arguments, e.g., for which
(proclaim '(function my-function (list vector) t))
has any effect different from
(proclaim '(function my-function (t t) t))
?
Does anyone *have* any Common Lisp code which contains such declarations? What
is the intent of the declarations, other than as documentation?
∂16-Dec-87 1045 Common-Lisp-mailer Current practice:argument types in function declarations
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 87 10:45:26 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 16 Dec 87 13:34-EST
Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 72595; 16 Dec 87 13:28:50-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 89445; Wed 16-Dec-87 13:03:38-EST
Date: Wed, 16 Dec 87 13:11 est
From: mike%acorn@oak.lcs.mit.edu
To: masinter.PA@Xerox.COM
Subject: Current practice:argument types in function declarations
Cc: common-lisp@sail.stanford.edu
From: masinter.PA@Xerox.COM
Date: 16 Dec 87 1:32:02 PST
>Is anyone aware of any (released? supported?) Common Lisp implementation that
>pays any attention at all to the types of arguments, e.g., for which
> (proclaim '(function my-function (list vector) t))
>has any effect different from
> (proclaim '(function my-function (t t) t))
> ?
>Does anyone *have* any Common Lisp code which contains such declarations?
>What is the intent of the declarations, other than as documentation?
First off, either signature tells you more than nothing at all, since
it fixes the number of arguments. Presumably, you have to check
the number of arguments as well as the types for really safe calls.
As for use, we are not using them currently, but plan to use them.
The goal is to generate "safe" calls for functions when compiling if
the type signature is unknown. If the type signature is known;
however, the checking burden is placed on the caller (and can be
minimized via type inference, etc.) and an unsafe call is generated.
The type signature can be known either via block compilation, or
by using function type proclamations. In any case if you ftype a function
and a call can be shown to contradict the proclamation, then you
should get a warning and a safe (slow) call.
The one difficulty with these things is that common lisp's type
language doesn't allow you to specify accurate types for things
like <. E.G.,
(proclaim '(ftype < (function (&rest ??) (or T nil))))
For ?? you'd like to say "zero or more non-complex numbers". You do
NOT want to say LIST here.
I am considering defining a (list-of ...) type specifier.
where the argument is a type. This cannot really be written in
common lisp, since it doesn't allow parameterized types in general.
But we as implementors can put it in place as an extension.
Mike Beckerle
Gold Hill Computers.
∂17-Dec-87 0004 Common-Lisp-mailer Re: Current practice:argument types in function declarations
Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 17 Dec 87 00:04:27 PST
Date: Thu, 17 Dec 87 03:05 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Re: Current practice:argument types in function declarations
To: masinter.PA@Xerox.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <871216-013219-2778@Xerox>
Message-ID: <871217030542.2.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: 401A CS Building, Computer Science Department, University of Rochester, Rochester NY 14627
Phone: 716-275-1118
Date: 16 Dec 87 1:32:02 PST
From: masinter.PA@Xerox.COM
Does anyone *have* any Common Lisp code which contains such declarations? What
is the intent of the declarations, other than as documentation?
All the code I write has such delcarations, including for the types of all
returned values. The immediate purpose is documentation since it's ignored on
the machine I happen to work on (a symbolics) but it's my hope that in future
the compiler/interpreter would complain about calls to the function that pass
the wrong type of argument at compile time, if it can tell. (runtime would
depend on OPTIMIZE SAFETY or some such, and probably local declarations inside
the defun or whatever).
Also, it could be used as a note to the debugger, since it could flag that an
argument was of an unexpected type if some other problem arises and it gets
invoked. (this would help track down the error).
But I'm a user, not an implementor: this is just what I hope to eventually get
out of it. As I said, right now it's just documentation so the next guy knows
what I expected the function to handle when I wrote it.
Brad Miller
------
miller@cs.rochester.edu {...allegra!rochester!miller}
Brad Miller
University of Rochester Computer Science Department
∂17-Dec-87 0735 Common-Lisp-mailer ε1Question about declarationε0
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 07:35:17 PST
Received: from XX.LCS.MIT.EDU (XX.LCS.MIT.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 26111; 17 Dec 87 10:36:14 EST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Dec 87 10:08-EST
Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 72757; 17 Dec 87 09:46:25-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 89447; Wed 16-Dec-87 13:11:58-EST
Date: Wed, 16 Dec 87 13:19 est
From: mike%acorn@oak.lcs.mit.edu
To: RWK@YUKON.SCRC.Symbolics.COM
Subject: ε1Question about declarationε0
Cc: miller@cs.rochester.edu, CL@ACORN.CS.ROCHESTER.EDU
Date: Fri, 11 Dec 87 10:54 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Date: Fri, 11 Dec 87 01:16 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
ε1 How would you write a function declaration for the following?
(defun foo (bar)
(declare (type list bar))
(values-list bar)
(proclaim '(function foo (list) ????))
ε0I wouldn't. CL doesn't have any syntax for declaring
a variable number of values, period.
I think you can do this in CL:
(function foo (list) (values &rest list))
see CLtL pg 48 under the values type specifier. The explaination for
this "feature" is motivated by multiple-value-call.
So presumably with this declaration, you can do
(multiple-value-call '+ (foo 1 2 3))
and get some kind of optimized call since it knows it's getting back
a variable number of values when FOO returns.
...mike beckerle
∂17-Dec-87 1048 Common-Lisp-mailer Types in CL
Received: from NRTC.NORTHROP.COM by SAIL.STANFORD.EDU with TCP; 17 Dec 87 10:48:26 PST
Date: Thu, 17 Dec 87 10:48:05 PST
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
To: common-lisp@sail.stanford.edu
cc: jbarnett@nrtc.northrop.com
Subject: Types in CL
Recently, there has been some message traffic concerning functional type
specification and related topics. The purpose of this note is to point
out two problems with the CL type mechanism that I have not seen
discussed: the first concerns a case were the value of TYPEP *must* be
undefined and the second concerns the definition of a subtype of a
functional type.
PROBLEM I. Assume that the following have been evaluated
(DEFTYPE T1 '(ARRAY T2 1))
(DEFTYPE T2 '(NOT T1))
Let A be a one-dimensional array of size 1 such that (EQ A (AREF A 0)).
What should the value of (TYPEP A 'T1) be? It is easy to see that A is
in type T1 if and only if it is not in type T1. A type specification
mechanism that allows (1) recursive definitions and (2) a negation
operation is sure to have this problem. Obviously, we want recursive
specification so that chains or rings of same-typed structures can be
specified and we want negation so that the programmer does not need to
explicitly list every possible alternative type in his definition.
PROBLEM II. Assume that the following return non-NIL
(SUBTYPEP 'T1 'T2)
(SUBTYPEP 'T2 'T3)
The question is what are the subtypes of the type specifier
(FUNCTION (T2) T2)
I think that the answer is
(FUNCTION (T3) T1)
because the type-specific contract of an F in type (FUNCTION (T2) T2) is
to (1) accept as arguments objects in T2 and (2) return objects in T2.
Therefore, an F that accepts objects in T3 (which includes all of T2)
and returns objects in T1 (all of which are in T2) satisfies that
contract. An F in (FUNCTION (T1) T3) does not because (1) it does not
promise to handle an object in T2-T1 and (2) may return an object in
T3-T2. Therefore,
(SUBTYPEP '(FUNCTION (T3) T1) '(FUNCTION (T2) T2))
should be non-NIL while
(SUBTYPEP '(FUNCTION (T1) T3) '(FUNCTION (T2) T2))
should be NIL. Note, as SUBTYPEP decomposes functional type
specifications and recurs, it must *reverse* the order of its arguments
when checking argument types---original order is used when value types
are checked. It is somewhat amusing to trace a case where the type
specification of either the arguments and/or the values are themselves
functional types or where functional types are recursively specified.
One reason to make sure that determining subtype-ness of functional
types is as accurate as it can be as often as possible arises because
most LISPS do incremental compilations and are interactive. If a
function is recompiled and either its argument or value types change, it
would be good to inform the user where there are calls that are no
longer type-compatible. IF THE NEW TYPE OF THE FUNCTION IS A SUBTYPE OF
THE OLD, THEN, AS FAR AS TYPE CHECKING IS CONCERNED, EVERYTHING MUST BE
OKAY. It is only when this is not true, that it is necessary to check
the types of objects actually passed to the function from other code or
see what assumptions have been made in consuming the returned objects.
There is a slight generalization of the comments as to what is a
reasonable definition of subtype of functional types. Assume that a
variable or register has been given a type specification. Let that type
specification be changed. There are three possibilities:
1. THE NEW TYPE SPECIFICATION IS A SUBTYPE OF THE OLD
Code that only reads the cell is not affected.
Code that writes the cell may or may not be valid.
2. THE NEW TYPE SPECIFICATION IS A SUPERTYPE OF THE OLD
Code that only writes the cell is not affected.
Code that reads the cell may or may not be valid.
3. THE NEW AND OLD TYPE SPECIFICATIONS ARE NOT COMPARABLE
Any code that reads the cell may or may not be valid.
The reason that the above implies the rules for functional subtype
determination is that, from the point of view of a function caller,
arguments represent write-only registers while values represent
read-only registers. A while ago, there was some discussion of having a
class of read-only goodies in LISP. If that is ever sanctioned, these
comments may provide some guidance in error checking interactions of
that mechanism with type declarations and revisions.
Jeff
∂17-Dec-87 1220 Common-Lisp-mailer Types in CL
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 17 Dec 87 12:20:30 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 17 Dec 87 15:19:56 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 17 Dec 87 15:19:52 EST
Date: Thu, 17 Dec 87 15:21 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Types in CL
To: Jeff Barnett <jbarnett@nrtc.northrop.com>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8712171849.AA02757@Think.COM>
Message-Id: <871217152141.3.BARMAR@OCCAM.THINK.COM>
Date: Thu, 17 Dec 87 10:48:05 PST
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
PROBLEM I. Assume that the following have been evaluated
(DEFTYPE T1 '(ARRAY T2 1))
(DEFTYPE T2 '(NOT T1))
Let A be a one-dimensional array of size 1 such that (EQ A (AREF A 0)).
By doing (SETF (AREF A 0) A) you have violated the type declaration you
specified, because you said that the elements of the array would never
be of the same type as the array itself, so a compiler would be
justified in assuming that (EQ A (AREF A 0)) is never true.
What should the value of (TYPEP A 'T1) be? It is easy to see that A is
in type T1 if and only if it is not in type T1. A type specification
mechanism that allows (1) recursive definitions and (2) a negation
operation is sure to have this problem.
Look up Russell's paradox (the one about the barber who shaves all and
only people who don't shave themselves, or the catalog of all books not
in any other catalog) in a logic book. Any sufficiently expressive
class system allows such classes to be specified, even though such sets
cannot actually exist because they are self-contradictory. Your example
isn't really like this, because the Lisp type system lacks the ability
to specify that an array of type T1 contains ALL objects of type T2.
barmar
∂17-Dec-87 1257 Common-Lisp-mailer Re: Types in CL
Received: from NRTC.NORTHROP.COM by SAIL.STANFORD.EDU with TCP; 17 Dec 87 12:57:21 PST
Date: Thu, 17 Dec 87 12:56:57 PST
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
To: Barry Margolin <barmar@think.com>
cc: Jeff Barnett <jbarnett@nrtc.northrop.com>,
common-lisp@sail.stanford.edu
Subject: Re: Types in CL
Your claim that the compiler should inhibit (SETF (AREF A 0) A) is only valid
if A is declared of type T1. It may not be. What you are pointing out is
that there is a problem if one tries to determine the type of an object (or
its type membership status) *after* the object is created. In fact, the
runtime package and compiler can offer you more protection if an object is
marked with a type when it is created; only then can modifications and so on
be checked locally. However this loses something that may not be obvious: an
object can not be referenced by a register unless its marked type entails ALL
type restrictions imposed by the reference. It is not sufficient that its
current configuration passes muster.
Jeff
P.S. The barber is an old friend.
∂17-Dec-87 1447 Common-Lisp-mailer Types in CL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 14:47:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306293; Thu 17-Dec-87 17:47:00 EST
Date: Thu, 17 Dec 87 17:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Types in CL
To: Jeff Barnett <jbarnett@nrtc.northrop.com>
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 17 Dec 87 13:48 EST from Jeff Barnett <jbarnett@nrtc.northrop.com>
Message-ID: <19871217224647.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 17 Dec 87 10:48:05 PST
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
PROBLEM I. Assume that the following have been evaluated
(DEFTYPE T1 '(ARRAY T2 1))
(DEFTYPE T2 '(NOT T1))
Let A be a one-dimensional array of size 1 such that (EQ A (AREF A 0)).
What should the value of (TYPEP A 'T1) be?
You need to re-read the definition of the ARRAY type specifier
on CLtL page 46, being careful also to read page 45, which doesn't
look it's part of this, but is necessary in order to understand it.
The -element-type- portion of the ARRAY type specifier doesn't mean
what you think it means.
This is interesting, because your "Problem I" is a good argument against
proposals that have been raised from time to time to change the definition
of the ARRAY type specifier to be what you thought it was.
This is probably all a digression from your real point. Since DEFTYPE
can do anything, especially in connection with SATISFIES, it is certainly
possible to create logically inconsistent type specifications, even though
the particular example you gave is not actually one.
∂17-Dec-87 1452 Common-Lisp-mailer Re: Types in CL
Received: from [8.2.0.18] by SAIL.STANFORD.EDU with TCP; 17 Dec 87 14:52:28 PST
Date: 17 Dec 1987 17:50-EST
Sender: NGALL@G.BBN.COM
Subject: Re: Types in CL
From: NGALL@G.BBN.COM
To: jbarnett@NRTC.NORTHROP.COM
Cc: common-lisp@SAIL.STANFORD.EDU
Message-ID: <[G.BBN.COM]17-Dec-87 17:50:23.NGALL>
In-Reply-To: The message of Thu, 17 Dec 87 10:48:05 PST from Jeff Barnett <jbarnett@nrtc.northrop.com>
Date: Thu, 17 Dec 87 10:48:05 PST
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
...
PROBLEM I. Assume that the following have been evaluated
(DEFTYPE T1 '(ARRAY T2 1))
(DEFTYPE T2 '(NOT T1))
Let A be a one-dimensional array of size 1 such that (EQ A (AREF A 0)).
What should the value of (TYPEP A 'T1) be?
...
Yes, a problem. CLtL should specify that the result of a call to TYPEP
that causes an identical subcall (i.e., it loops) is undefined. Here
is a related (but perhaps better motivated example):
(DEFTYPE TREE (LEAF-TYPE) `(OR ,LEAF-TYPE (VECTOR TREE 2)))
(SETF CIRC-TREE '#(NIL NIL))
(FILL CIRC-TREE CIRC-TREE)
(TYPEP CIRC-TREE '(TREE INTEGER)) => {undefined}
This same problem affects CLtL's definitions of LIST, TRUE-LIST, and
DOTTED-LIST on pg. 28: A circular list is a LIST that is not a TRUE-LIST or
a DOTTED-LIST...
PROBLEM II. Assume that the following return non-NIL
(SUBTYPEP 'T1 'T2)
(SUBTYPEP 'T2 'T3)
The question is what are the subtypes of the type specifier
(FUNCTION (T2) T2)
I think that the answer is
(FUNCTION (T3) T1)
because the type-specific contract of an F in type (FUNCTION (T2) T2) is
to (1) accept as arguments objects in T2 and (2) return objects in T2.
Therefore, an F that accepts objects in T3 (which includes all of T2)
and returns objects in T1 (all of which are in T2) satisfies that
contract. An F in (FUNCTION (T1) T3) does not because (1) it does not
promise to handle an object in T2-T1 and (2) may return an object in
T3-T2. Therefore,
(SUBTYPEP '(FUNCTION (T3) T1) '(FUNCTION (T2) T2))
...
The type specifier (FUNCTION ...) is not acceptable to TYPEP (pg. 47),
therefore it is not acceptable to SUBTYPEP (pg. 72).
-- Nick
∂17-Dec-87 1603 Common-Lisp-mailer Re: Types in CL
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 17 Dec 87 16:03:40 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 17 Dec 87 19:03:09 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 17 Dec 87 19:03:05 EST
Date: Thu, 17 Dec 87 19:04 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: Types in CL
To: Jeff Barnett <jbarnett@nrtc.northrop.com>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8712172057.AA00603@Think.COM>
Message-Id: <871217190451.6.BARMAR@OCCAM.THINK.COM>
Date: Thu, 17 Dec 87 12:56:57 PST
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
Your claim that the compiler should inhibit (SETF (AREF A 0) A) is only valid
if A is declared of type T1.
I never said anything about the compiler inhibiting the SETF. I said
that it is incorrect to do the SETF. However, you are correct that I
was wrong; you didn't show the MAKE-ARRAY form, and I assumed A was
created with
(setq a (make-array 1 :element-type 't2))
It may not be. What you are pointing out is
that there is a problem if one tries to determine the type of an object (or
its type membership status) *after* the object is created.
Actually, there is a bug in your original message, in the TYPEP call.
The predicate
(TYPEP A 'T1)
expands to
(TYPEP A '(ARRAY T2 1))
which is equivalent to
(AND (ARRAYP A)
(EQ (ARRAY-ELEMENT-TYPE A) 'T2)
(= (ARRAY-RANK A) 1)
(= (ARRAY-DIMENSION A 0) 1))
Note that it never does an AREF, so the question of whether (AREF A 0)
is of type T2 never comes up. When array types are used in TYPEP, the
element type does not refer to the current contents, but to the array's
implementation type.
In order to create the type anomaly you describe, you must use the
SATISFIES type specifier, e.g.
(DEFUN T1P (A)
(AND (ARRAYP A)
(= (ARRAY-RANK A) 1)
(= (ARRAY-DIMENSION A 0) 1)
(TYPEP (AREF A 0) 'T2)))
(DEFTYPE T1 () '(SATISFIES T1P))
When you do this, (TYPEP A 'T1) is guaranteed to infinitely recurse.
Because Lisp's type system permits arbitrary code to be incorporated,
the type system is Turing-equivalent, which means that the halting
problem exists. Without SATISFIES, though, the problem you describe
doesn't exist, because none of the other type specifiers require doing a
TYPEP of constituents of the object being tested (actually, I think
(TYPEP A '(COMPLEX <type>)) is an abbreviation for
(AND (COMPLEXP A)
(TYPEP (REALPART A) '<type>)
(TYPEP (IMAGPART A) '<type>))
but no recursion can occur because the parts of a complex number cannot
be complex).
barmar
∂17-Dec-87 1634 Common-Lisp-mailer Types in CL
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 17 Dec 87 16:34:46 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 17 Dec 87 19:34:15 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 17 Dec 87 19:34:11 EST
Date: Thu, 17 Dec 87 19:35 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Types in CL
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Jeff Barnett <jbarnett@nrtc.northrop.com>, common-lisp@sail.stanford.edu
In-Reply-To: <19871217224647.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <871217193557.7.BARMAR@OCCAM.THINK.COM>
Date: Thu, 17 Dec 87 17:46 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
This is probably all a digression from your real point. Since DEFTYPE
can do anything, especially in connection with SATISFIES, it is certainly
possible to create logically inconsistent type specifications, even though
the particular example you gave is not actually one.
Ah, yes, I just did
(deftype random-type () `(member ,(random 10)))
In this case, even
(and (typep x 'random-type)
(typep x 'random-type))
can be false, and you can go crazy trying to call a function defined
(defun random-function (x)
(check-type x random-type)
...)
By the way, this shows that I was wrong in my last message, when I said
that recursion isn't possible unless SATISFIES is used. All you need to
do is
(deftype int-greater-than (n)
(labels ((rest (n) (cons n (rest (1+ n)))))
`(member .,(rest (1+ n)))))
Conceptually, the type specifier (int-greater-than N) is equivalent to
(integer (N) *), but it'll never work with TYPEP.
barmar
∂18-Dec-87 0629 Common-Lisp-mailer Re: Current practice:argument types in function declarations
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 06:29:40 PST
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08775; Fri, 18 Dec 87 09:29:25 EST
From: <samalone@ATHENA.MIT.EDU>
Received: by M16-034-12.MIT.EDU (5.45/4.7) id AA10133; Fri, 18 Dec 87 09:29:16 EST
Message-Id: <8712181429.AA10133@M16-034-12.MIT.EDU>
To: common-lisp@sail.stanford.edu
Subject: Re: Current practice:argument types in function declarations
Date: Fri, 18 Dec 87 09:29:12 EST
Yes, I often proclaim functions to take arguments of specific types.
Usually this happens when I want to proclaim the return value of a
function and my sense of taste insists that I proclaim the types of the
arguments as well. However, none of the implementations I've used seem
to do much with the information.
There is one time when proclaiming the types of arguments to a function is
obviously useful: when compiling the function itself. True, one could
use declarations inside of the function to achive the same result, but
using a proclamation keeps all of the function's type specification in one place.
Without repeating them, I'd also like to voice my support of the
comments made by Mike Bekerle and Brad Miller.
--Stuart A. Malone
∂24-Dec-87 1442 Common-Lisp-mailer Re: Types in CL
Received: from NSS.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 24 Dec 87 14:42:30 PST
Received: from computer-lab.cambridge.ac.uk by NSS.Cs.Ucl.AC.UK
via Janet with NIFTP id aa05382; 24 Dec 87 16:10 GMT
To: cam-common-lisp%computer-lab.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK
Date: Thu, 17 Dec 87 19:04 EST
From: Barry Margolin <barmar@think.com>
Subject: Re: Types in CL
Original-To: Jeff Barnett <jbarnett@com.northrop.nrtc>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8712172057.AA00603@Think.COM>
Message-Id: <871217190451.6.BARMAR@OCCAM.THINK.COM>
Sender: pb%computer-lab.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK
Date: Thu, 17 Dec 87 12:56:57 PST
From: Jeff Barnett <jbarnett@nrtc.northrop.com>
Your claim that the compiler should inhibit (SETF (AREF A 0) A) is only valid
if A is declared of type T1.
I never said anything about the compiler inhibiting the SETF. I said
that it is incorrect to do the SETF. However, you are correct that I
was wrong; you didn't show the MAKE-ARRAY form, and I assumed A was
created with
(setq a (make-array 1 :element-type 't2))
It may not be. What you are pointing out is
that there is a problem if one tries to determine the type of an object (or
its type membership status) *after* the object is created.
Actually, there is a bug in your original message, in the TYPEP call.
The predicate
(TYPEP A 'T1)
expands to
(TYPEP A '(ARRAY T2 1))
which is equivalent to
(AND (ARRAYP A)
(EQ (ARRAY-ELEMENT-TYPE A) 'T2)
(= (ARRAY-RANK A) 1)
(= (ARRAY-DIMENSION A 0) 1))
Note that it never does an AREF, so the question of whether (AREF A 0)
is of type T2 never comes up. When array types are used in TYPEP, the
element type does not refer to the current contents, but to the array's
implementation type.
In order to create the type anomaly you describe, you must use the
SATISFIES type specifier, e.g.
(DEFUN T1P (A)
(AND (ARRAYP A)
(= (ARRAY-RANK A) 1)
(= (ARRAY-DIMENSION A 0) 1)
(TYPEP (AREF A 0) 'T2)))
(DEFTYPE T1 () '(SATISFIES T1P))
When you do this, (TYPEP A 'T1) is guaranteed to infinitely recurse.
Because Lisp's type system permits arbitrary code to be incorporated,
the type system is Turing-equivalent, which means that the halting
problem exists. Without SATISFIES, though, the problem you describe
doesn't exist, because none of the other type specifiers require doing a
TYPEP of constituents of the object being tested (actually, I think
(TYPEP A '(COMPLEX <type>)) is an abbreviation for
(AND (COMPLEXP A)
(TYPEP (REALPART A) '<type>)
(TYPEP (IMAGPART A) '<type>))
but no recursion can occur because the parts of a complex number cannot
be complex).
barmar
∂26-Dec-87 1933 Common-Lisp-mailer Question about declaration
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 87 19:33:48 PST
Received: from cayuga.cs.rochester.edu (CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 26527; 26 Dec 87 22:34:12 EST
Received: by cayuga.cs.rochester.edu (5.52/h) id AA17008; Sat, 26 Dec 87 22:32:26 EST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 311778; Sat 26-Dec-87 17:46:14 EST
Date: Sat, 26 Dec 87 22:32 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Question about declaration
To: mike%acorn@oak.lcs.mit.edu
Cc: RWK@YUKON.SCRC.Symbolics.COM, miller@cs.rochester.edu,
CL@ACORN.CS.ROCHESTER.EDU
In-Reply-To: The message of 16 Dec 87 13:19 EST from mike%acorn@oak.lcs.mit.edu
Message-Id: <19871227033217.8.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Wed, 16 Dec 87 13:19 est
From: mike%acorn@oak.lcs.mit.edu
Date: Fri, 11 Dec 87 10:54 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Date: Fri, 11 Dec 87 01:16 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
How would you write a function declaration for the following?
(defun foo (bar)
(declare (type list bar))
(values-list bar)
(proclaim '(function foo (list) ????))
I wouldn't. CL doesn't have any syntax for declaring
a variable number of values, period.
I think you can do this in CL:
(function foo (list) (values &rest list))
see CLtL pg 48 under the values type specifier. The explaination for
this "feature" is motivated by multiple-value-call.
Yes, but you haven't really declared those values, have you?
All you've done is declare that you can have a "list of them".
Now, if there was a "sequence-enumerated" type (as we have
in our UIMS), this would be a different matter. I.e.
(function foo ((and list (sequence-enumerated symbol integer symbol integer)))
(values &rest (and list (sequence-enumerated symbol integer symbol integer))))
So presumably with this declaration, you can do
(multiple-value-call '+ (foo 1 2 3))
and get some kind of optimized call since it knows it's getting back
a variable number of values when FOO returns.
...mike beckerle
But what you'd *like* to know here is that the individual elements are integers;
i.e.
(function foo ((list integer))
(values &rest (list integer)))
where the new argument to LIST does *NOT* work like ARRAY (meaning "a kind of
list specialized to contain only integers"), but rather means "a list whose
elements are all INTEGER's".
There is a big gap between being able to declare the existence of
a variable number of arguments or values and being able to declare
their type.
∂27-Dec-87 1421 Common-Lisp-mailer Types in CL
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Dec 87 14:21:33 PST
Received: by labrea.stanford.edu; Sun, 27 Dec 87 14:21:39 PST
Received: from bhopal.lucid.com by edsel id AA20288g; Sun, 27 Dec 87 13:14:07 PST
Received: by bhopal id AA02168g; Sun, 27 Dec 87 13:15:46 PST
Date: Sun, 27 Dec 87 13:15:46 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8712272115.AA02168@bhopal.lucid.com>
To: labrea!barmar%think.com@labrea.stanford.edu
Cc: labrea!common-lisp%sail@labrea.stanford.edu
In-Reply-To: Barry Margolin's message of Thu, 17 Dec 87 19:04 EST <871217190451.6.BARMAR@OCCAM.THINK.COM>
Subject: Types in CL
re:
Actually, there is a bug in your original message, in the TYPEP call.
The predicate
(TYPEP A 'T1)
expands to
(TYPEP A '(ARRAY T2 1))
which is equivalent to
(AND (ARRAYP A)
(EQ (ARRAY-ELEMENT-TYPE A) 'T2)
(= (ARRAY-RANK A) 1)
(= (ARRAY-DIMENSION A 0) 1))
This isn't right, and is probably a good example of the single most common
error when trying to figure out what the array types mean. Since a CL
implementation of arrays is permitted to "upgrade" the :element-type
argument into something actually supported, and since there is no
requirement to preserve the original :element-type argument, then the
line above
(EQ (ARRAY-ELEMENT-TYPE A) 'T2)
should be
(SUBTYPEP 'T2 (ARRAY-ELEMENT-TYPE A))
Of course, optimizations are possible for specific T2's; but in general
the element-type might have been upgraded to, for example, T.
-- JonL --
∂28-Dec-87 0838 Common-Lisp-mailer Types in CL
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Dec 87 08:37:59 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 28 Dec 87 11:37:32 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 28 Dec 87 11:37:29 EST
Date: Mon, 28 Dec 87 11:38 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Types in CL
To: Jon L White <edsel!jonl@labrea.stanford.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8712272115.AA02168@bhopal.lucid.com>
Message-Id: <871228113827.1.BARMAR@OCCAM.THINK.COM>
Date: Sun, 27 Dec 87 13:15:46 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
re:
Actually, there is a bug in your original message, in the TYPEP call.
The predicate
(TYPEP A 'T1)
expands to
(TYPEP A '(ARRAY T2 1))
which is equivalent to
(AND (ARRAYP A)
(EQ (ARRAY-ELEMENT-TYPE A) 'T2)
(= (ARRAY-RANK A) 1)
(= (ARRAY-DIMENSION A 0) 1))
This isn't right, and is probably a good example of the single most common
error when trying to figure out what the array types mean. Since a CL
implementation of arrays is permitted to "upgrade" the :element-type
argument into something actually supported, and since there is no
requirement to preserve the original :element-type argument, then the
line above
(EQ (ARRAY-ELEMENT-TYPE A) 'T2)
should be
(SUBTYPEP 'T2 (ARRAY-ELEMENT-TYPE A))
Of course, optimizations are possible for specific T2's; but in general
the element-type might have been upgraded to, for example, T.
This contradicts an explicit statement to the contrary in CLtL. On page
46, it says:
(ARRAY CHARACTER) is not the set of all arrays that can hold
characters, but rather the set of arrays that are specialized to
hold characters and no other objects. To test whether an array FOO
can hold a character, one should not use
(TYPEP FOO '(ARRAY CHARACTER))
but rather
(SUBTYPEP 'CHARACTER (ARRAY-ELEMENT-TYPE FOO))
I therefore stand by my translation.
barmar
∂28-Dec-87 0848 Common-Lisp-mailer Types in CL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Dec 87 08:48:19 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 310888; Mon 28-Dec-87 11:24:56 EST
Date: Mon, 28 Dec 87 11:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Types in CL
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8712272115.AA02168@bhopal.lucid.com>
Message-ID: <19871228162446.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 27 Dec 87 13:15:46 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
re:
Actually, there is a bug in your original message, in the TYPEP call.
The predicate
(TYPEP A 'T1)
expands to
(TYPEP A '(ARRAY T2 1))
which is equivalent to
(AND (ARRAYP A)
(EQ (ARRAY-ELEMENT-TYPE A) 'T2)
(= (ARRAY-RANK A) 1)
(= (ARRAY-DIMENSION A 0) 1))
This isn't right, and is probably a good example of the single most common
error when trying to figure out what the array types mean. Since a CL
implementation of arrays is permitted to "upgrade" the :element-type
argument into something actually supported, and since there is no
requirement to preserve the original :element-type argument, then the
line above
(EQ (ARRAY-ELEMENT-TYPE A) 'T2)
should be
(SUBTYPEP 'T2 (ARRAY-ELEMENT-TYPE A))
Of course, optimizations are possible for specific T2's; but in general
the element-type might have been upgraded to, for example, T.
Just to keep the record 100% straight, SUBTYPEP isn't right.
It's true that MAKE-ARRAY and DECLARE upgrade the element type,
but TYPEP does not.
CLtL p.46 says the ARRAY type specifier -for- -discrimination-
(i.e. when used with the TYPEP function) means arrays specialized
to hold precisely the mentioned element type and no other objects,
unless the mentioned element type is *, which means all arrays.
See also the second to last paragraph on p.45. This is all a bit
strange, but it's what the book says. I suspect there are reasons
for it. We've been through this a million times on the Common Lisp
mailing list, and no one, including you and me, can remember it without
looking it up in the book each time, so it must be unintuitive.
EQ isn't right either. The function you really want is EQUAL-TYPEP,
which doesn't exist in Common Lisp, since two type specifiers can
certainly be equivalent without being EQ, and in fact without being EQUAL.
An adequate definition is probably
(defun equal-typep (t1 t2)
(and (subtypep t1 t2) (subtypep t2 t1)))
∂29-Dec-87 1126 Common-Lisp-mailer implicit blocks
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 87 11:26:12 PST
Posted-Date: Tue, 29 Dec 87 11:26:20 PST
Message-Id: <8712291926.AA29210@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA29210; Tue, 29 Dec 87 11:26:23 PST
To: COMMON-LISP@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: implicit blocks
Date: Tue, 29 Dec 87 11:26:20 PST
Sender: goldman@vaxa.isi.edu
CLtL specifies that the body of a defun is implicitly surrounded by a
block with the same name as the defun. As far as I can find, it makes
no such stipulation about the bodies of named lexical functions introduced
with FLET or LABELS, nor for macro bodies (defmacro, macrolet).
Of the three implementations I have looked at, two do supply implicit
blocks for FLET, LABELS, and DEFMACRO (I didn't check for macrolet),
and one supplies an implicit block ONLY for DEFUN.
Has this been clarified in earlier discussions?
From the standpoint of transforming code, it would be desireable
for the implicit block to be supplied in either ALL or NONE of
the above. From the standpoint of utility, I would suggest ALL.
Neil
∂29-Dec-87 1206 Common-Lisp-mailer Types in CL
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 87 12:06:37 PST
Received: by labrea.stanford.edu; Tue, 29 Dec 87 12:06:28 PST
Received: from bhopal.lucid.com by edsel id AA25479g; Tue, 29 Dec 87 11:55:22 PST
Received: by bhopal id AA09443g; Tue, 29 Dec 87 11:57:10 PST
Date: Tue, 29 Dec 87 11:57:10 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8712291957.AA09443@bhopal.lucid.com>
To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu,
labrea!barmar%Think.COM@labrea.stanford.edu
Cc: labrea!common-lisp%SAIL@labrea.stanford.edu
Subject: Types in CL
CLtL, p45, clearly permits the "upgrade" for arrays -- namely that a request
for an array of element-type T2 is satisified by an array of element-type
T2*, where (SUBTYPEP T2 T2*) and where T2* is the "least" such type.
For example, if an implementation only has "general" arrays and "8-bit"
arrays, then
(MAKE-ARRAY <n> :ELEMENT-TYPE '(UNSIGNED-BYTE 5))
could legitimately return an array of element-type '(UNSIGNED-BYTE 8).
But it would not be satisfied by a "general" type array, since there is
a kind of array with more specialized element-type that can hold
(unsigned-byte 5)'s.
Note that (UNSIGNED-BYTE 5) is *not* even equal-typep to (UNSIGNED-BYTE 8).
[And certainly not EQ!]
However, the problem with TYPEP that you [Moon] describe is clearly one of
the most serious flaws in the CL design -- that a variable declared to be
of type
<certain-type>
and all of whose objects are created in accord with that type-specifier,
still may have *none* of its values ever satisfied by the TYPEP predicate
with that type-specifier.
We have received repeated bug reports from users whenever
(TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE '<certain-type>)
'(ARRAY <certain-type> *))
is false. Many of us have reverted to treating this part of CLtL as
an unworkable braino with no particular utility. If you or anyone else
cares to defend the typep warp, I'd be curious to hear about it.
The more generous interpretation of array element-type upgrading would
permit the two array type specifiers
(ARRAY (UNSIGNED-BYTE 5) *)
(ARRAY (UNSIGNED-BYTE 8) *)
to be equal-typep [in the above hypothetical implementation], even though
the two element types
(UNSIGNED-BYTE 5)
(UNSIGNED-BYTE 8)
are not equal-typep.
-- JonL --
∂30-Dec-87 1631 Common-Lisp-mailer function redefinition.
Received: from SALLY.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 30 Dec 87 16:31:39 PST
Posted-Date: Wed, 30 Dec 87 18:09:53 CST
Received: by sally.utexas.edu (5.54/5.51)
id AA10289; Wed, 30 Dec 87 18:31:42 CST
Date: Wed, 30 Dec 87 18:09:53 CST
From: wfs@rascal.ics.utexas.edu (Bill Schelter)
Message-Id: <8712310009.AA11780@rascal.ics.utexas.edu>
Received: by rascal.ics.utexas.edu (3.2/4.22)
id AA11780; Wed, 30 Dec 87 18:09:53 CST
To: common-lisp@sail.stanford.edu
Subject: function redefinition.
Two questions involving changing of a symbol-function of a symbol.
I) Is it permissible in common lisp for a function FOO
to call a function which may redefine FOO?
This is useful for defining autoloading, or self compiling
functions. I was not able to find anything in the manual
authorizing this. I would like to use this feature, in some
code which I want to be very pure common lisp.
Does anyone know of a common lisp implementation where this
is not valid, or perhaps some text in the manual which might
authorize such behaviour?
Example:
(defun foo (&rest l)
(load "foo-def.o")
(apply 'foo l))
II) What is the approved order of evaluation of in the call
(foo a), or is it left undefined.
For examble if I have a file containing the following three forms:
(defun foo (x) x (print "hi"))
(defun goo (y) x (print "bye"))
(defun test () (foo (setf (symbol-function 'foo) (symbol-function 'goo))) )
Then for symbolics and kcl,
interpreted (test) ==> "hi"
compiled (test) ==> "bye"
I am happy with the order being undefined, I just wondered if this
was indeed supposed to be so, or if I should fix it in kcl.
Of course for speed in compilation, the "bye" answer is what
fits in most easily, since you want we want to push the args
and then call the function, so we don't want to have to save
its address before pushing the args.
Bill Schelter
∂31-Dec-87 0731 Common-Lisp-mailer Teaching iteration
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 87 07:31:42 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA16304@EDDIE.MIT.EDU>; Thu, 31 Dec 87 10:30:21 EST
Received: from zaphod.prime.com by primerd.prime.com (3.2/SMI-3.0DEV3/smail)
id AA19852; Thu, 31 Dec 87 10:22:34 EST
Received: by zaphod.prime.com (3.2/SMI-3.2)
id AA04386; Thu, 31 Dec 87 10:24:46 EST
Date: Thu, 31 Dec 87 10:24:46 EST
From: primerd!zaphod!doug@EDDIE.MIT.EDU (Douglas Rand)
Message-Id: <8712311524.AA04386@zaphod.prime.com>
To: common-lisp@sail.stanford.edu
Subject: Teaching iteration
I have a generic question. I've been teaching a group Common LISP and will
be teaching a group of engineers here at Prime. Up to now I've kept within
CLtL for constructs. However, at this point, there are two really nicely
done LOOP macros freely available. Both the MIT supplied and the UTEXAS
supplied macros seem reliable and produce good code with lots of type
declarations for those compilers that use them.
The question is: Is it safe to teach this group LOOP rather then DO, DO*,
DOTIMES, DOLIST and minimal LOOP? I rather like LOOP's declarative style
and find the resulting code both more flexible and more readable.
Replies can be send directly unless the whole group really wants another
discussion topic.
Cheer,s
Doug (dougr@eddie.mit.edu)
P.S. Please don't use reply, it doesn't seem to get me my mail these days.
P.P.S. Happy New Year
∂31-Dec-87 0831 Common-Lisp-mailer sloop availability
Received: from SALLY.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 87 08:31:47 PST
Posted-Date: Thu, 31 Dec 87 09:56:47 CST
Received: by sally.utexas.edu (5.54/5.51)
id AA21787; Thu, 31 Dec 87 10:31:40 CST
Date: Thu, 31 Dec 87 09:56:47 CST
From: wfs@rascal.ics.utexas.edu (Bill Schelter)
Message-Id: <8712311556.AA12729@rascal.ics.utexas.edu>
Received: by rascal.ics.utexas.edu (3.2/4.22)
id AA12729; Thu, 31 Dec 87 09:56:47 CST
To: common-lisp@sail.stanford.edu
Cc: mcvax!jungfrau!ceb@uunet.uu.net
Subject: sloop availability
In reply to the letter asking about sloop.lisp
It is available on rascal:/usr2/ftp/pub/sloop.lisp
Internet Address:
128.83.144.1 rascal.ics.utexas.edu rascal # sun unix
login anonymous with password guest.
If you cannot ftp, send a request message to
wfs@racal.ics.utexas.edu
and I will mail it to you.
Any bug reports or complaints (or even contented user reports)
should also go to that address.
Bill Schelter
∂31-Dec-87 1116 Common-Lisp-mailer implicit blocks
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 31 Dec 87 11:16:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 313137; Thu 31-Dec-87 14:16:19 EST
Date: Thu, 31 Dec 87 14:16 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: implicit blocks
To: goldman@vaxa.isi.edu
cc: COMMON-LISP@SAIL.STANFORD.EDU
In-Reply-To: <8712291926.AA29210@vaxa.isi.edu>
Message-ID: <19871231191610.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 29 Dec 87 11:26:20 PST
From: goldman@vaxa.isi.edu
CLtL specifies that the body of a defun is implicitly surrounded by a
block with the same name as the defun. As far as I can find, it makes
no such stipulation about the bodies of named lexical functions introduced
with FLET or LABELS, nor for macro bodies (defmacro, macrolet).
Of the three implementations I have looked at, two do supply implicit
blocks for FLET, LABELS, and DEFMACRO (I didn't check for macrolet),
and one supplies an implicit block ONLY for DEFUN.
Has this been clarified in earlier discussions?
From the standpoint of transforming code, it would be desireable
for the implicit block to be supplied in either ALL or NONE of
the above. From the standpoint of utility, I would suggest ALL.
The Cleanup subcommittee of X3J13 decided in issue FLET-IMPLICIT-BLOCK
that all of these have implicit blocks. These cleanup changes have
no "official" status yet, and an implementation that doesn't do
implicit blocks for other than DEFUN is just as "correct" as one that
does. However, implementations should be migrating in the direction
of supplying implicit blocks for all of these.
Send mail to Masinter.pa@Xerox.COM if you want a copy of the text of
the FLET-IMPLICIT-BLOCK cleanup.
∂31-Dec-87 1634 Common-Lisp-mailer Re: implicit blocks
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 31 Dec 87 16:34:44 PST
Received: from Burger.ms by ArpaGateway.ms ; 31 DEC 87 16:35:11 PST
Sender: "Larry_Masinter.PARC"@Xerox.COM
Date: 31 Dec 87 16:34:23 PST (Thursday)
Subject: Re: implicit blocks
From: masinter.PARC@Xerox.COM
To: COMMON-LISP@SAIL.STANFORD.EDU
In-Reply-to: Common-Lisp-mailer%SAIL.Stanford:EDU's message of 31 Dec 87
11:43:32 PST (Thursday)
Message-ID: <871231-163511-2608@Xerox>
There will probably be a letter ballot to X3J13 to confirm the cleanup items
accepted by voice vote at the recent X3J13 meetings. I'd say that these changes
would then has as much `official' status as anything.
I'll send out to common-lisp the text of the proposals, although probably not
soon. This is FLET-IMPLICIT-BLOCK:
!
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Category: OMISSION
Edit history: Version 2 by cleanup committee 15-Mar-87 15:13:33
Version 3 by Masinter (reformatting) 7-Apr-87 17:49:12
Versions 4,5 by Fahlman 11-Apr-87
Version 6 by Masinter 5-Jun-87
Problem Description:
Do FLET, LABELS, DEFMACRO, MACROLET, DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE have an implicit block around their bodies like the body of a
DEFUN? CLtL is silent on this point. Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with DEFUN.
Test case:
(defun test ()
(flet ((test (x) (if x (return-from test 4) 3)))
(list (test nil) (test t))))
(test)
will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would
return 4 in an implementation that did not add an implicit block around
FLET.
Proposal: FLET-IMPLICIT-BLOCK:YES
Each function created by FLET and LABELS and each macro created by
DEFMACRO and MACROLET has an implicit block around the body. The name
of this block is that same as the (lexical) name of the function or
macro. Similarly, the body code in DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE is surrounded by a block with the same name as the accessor or
type.
Current Practice:
Current practice is mixed. Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.
Cost of adopting this change:
Some implementations will have to be modified. This should be a
relatively easy modification.
Cost of not adopting the change:
If the issue is not clarified one way or another, continuing confusion
will result in portability problems. Clarifying the issue in any other
way would also require modifications in some implementations.
Cost of converting existing code:
It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block. Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect. It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.
Discussion:
The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions. The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.
Two alternatives to the proposal were considered and rejected:
The first would be to keep the implicit block in DEFUN, and to clearly
state that the other forms do not create implicit blocks. This violates
the goal of consistency between lexical and global definitions, and it
seems to conflict with users' expectations.
The second alternative was to eliminate the implicit block from DEFUN
rather than adding such blocks to other forms. There was some feeling
that specifying the implicit block in DEFUN was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself. If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.
However, eliminating the implicit block in DEFUN would be a significant
incompatible change. Some users find this implicit block to be a great
convenience for popping out of convoluted code, and some existing code
makes heavy use of this feature. While such code could be repaired
automatically by searching for situations in which the user returns from
a function by name and by adding an appropriate explicit block to any
function containing such a forms, it would still require more more work
on existing user code than this proposal made above.
There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common in future Common Lisp
implementations. The outcome of these discussions was general agreement
that a compiler could easily eliminate the implicit block in any case
where it is not actually used, and that the impact on tail-recursion
optimization in compiled code is therefore minimal.